AppleBus: 

An Introduction 



Apple CcMnputer'^ mission is to provide people with inexpensive, easy-to-use 
computers. Apple now introduces AppleBus, a simple interconnect system that delivers 
all the benefits of multi-user communication and shared resources at a fraction of the cost 
usually associated with these features. 

AppleBus adds a powerful new dimension to Apple's computer products by allowing 
them to communicate freely for cooperative purposes without in any way diminishing the 
independence of the individual user. 

AppleBus functi<ms in three major configurations: as a small area intercmuiect 
system, as a tributary to a larger network, and in its most elemental form, as a peripheral 
bus between an Apple computer and its dedicated attached devices. 

As a stand-alone work area network. AppleBus provides communicatims and resource 
sharing amcmg up to 32 computers, disks, printers, modems, and other peripherals. More 
important. AppleBus supports a wide variety of forthcoming services such as shared 
files, electronic mail, and oommunicatim with computers and resources on other 
networks. Further, AppleBus has been designed to allow its incorporation, through 
bridging devices, into larger networks. 

When functioning as a peripheral bus, Apple Bus in effect implements the concept of 
slots by providing a single serial bus for the ctmnection of a variety of peripheral 
devices. 

To achieve this range of flexibility, Apple has designed highly reliable, inexpensive 
hardware, and a sophisticated set of communicatims protocols. This hardware /software 
package, together with the ccanputers, cables and cwinectors, shared resource managers 
(servers), and specialized applications software, will grow into a complete line of 
products offered both by Apple and third parties, (see figure 1) 

Design Goals 

Applebus is designed to fit the needs of the individual user who wishes to extend his 
maximum number of directly-attached peripherals, and provide for the sharing 
requirements of a small cluster of computers. Careful attention has also been paid to 
businesses, where work area networks feed large backbme networks and corporate 
communication implies a mixture of networks and technologies. 



Work Stations 


Servers 







Peripherals 


Herd Disk 


Printer 


_i'=g 


Other Peripherel 



other Netwwks 


Figure 1. AppleBus System 



1. Low-oost 


AppleBus is built into Macintosh and Lisa. The shielded. twisted»pair cable used to 
form the bus. and its associated cables and connectors, bring the actual cost to only about 
$25 per connect for any ccxifiguration. 

2. Easy to Install 

Electrically. AppleBus is designed with passive (transformer) coupling of devices to 
a trunk cable, with simple. selMerminating miniature DIN connectors. No special 
installation is necessary, and computers, peripherals, or servers may be easily relocated 
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or added. The actual cmnection of a device to AppleBus is simpler than hooking stereo 
speakers to a "hi-fi* system. 

3. Easy to Extend 

The AppleBus Protocols Package supports a range of configurations from simple 
dedicated device attachment through internetworking. With the same software. AppleBus 
may be extended through AppleBus bridges to other AppleBuses. and through gateways to 
communications services and other networks (local or long-haul). 

4. Op«n Systems Architecture 

Apple has developed a suite of protocols for AppleBus which provide functionality 
corresponding to the various layers of the ISO (International Standards Organization) OSI 
(Open Systems Intercomiection) reference model. Protocols at the ISO-OSI layers 1 
through 5 (Physical. Data Link. Network. Transport, and Session) form the core of the 
AppleBus Protocol Architecture. The use of the ISO-OSI layering allows developers to 
design new functions and applications for AppleBus. Throughout the development of 
AppleBus. Apple will make all technical documentatiwi completely public. 

Technical Specificatiofis 
Hardware 

AppleBus at the Physical level has a bus topology consisting of a linear trunk cable 
vrith intervening connectiwi modules to which nodes attach via a short drop cable. 
Electrically and mechanically. AppleBus is a multi-drop, balanced, transformer isolated 
serial ccHnmunicati<xi6 system for up to 32 nodes. The raw data rate is 230.4K baud over a 
distance of 300 meters. 



The serial hardware driver in Macintosh and Lisa (Zilog 8530 Serial Communications 
Controller) is programmed to use SDLC frame format, and FM 0 modulation. FM 0 is a bit 
encoding technique that provides self-clocking. Balanced signalling is achieved using 
RS-422 driver and receiver ICs in each of the attached devices. The transformer 
provides ground isolation as well as protection from static discharge. Since a node is 
passively connected to the trunk cable via a drop cable, a device may fail without 
disturbing communications. Nodes may be added and removed from the bus with only 
minor disruption of service. 

Since end-user installation is assumed, assemble cables will be sold in standard 2. 6. 
and IS meter lengths with molded miniature DIN connectors. The trunk cable connects to 
an AppleBus connection module. The cwmection module is a small plastic case (3*x 2““x 
1*) containing a transformer, resistive and capacitive circuits for ix>ise immunity, and 
two 3-pin miniature DIN connectors with terminating switches to a 100 ohm terminating 
resistor. Attached to this plastic case is an 18 inch "drop cable* which terminates at the 
node with either a DB-9 or DB-2S connector. The trunk cable is shielded, twisted pair 
cable (Belden 9272 or equivalent). 

For detailed hardware informatimt, refer to AppleBus Electrical / Mechanical 
Specification. March. 1984 (Apple Doc No. 062-0190-A). 

Protocols and Software 

Underlying all use of AppleBus is a specific set of protocols, or communication 
* rules*. These protocols correspond to the ISO-OSI layers 1 through S (Physical, Data 
Link. Network, Transport, and Session). 

Whiie Apple recommends the use of these protocols, communication over AppleBus is 
not dependent on their exclusive use. All protocol implementati<ms are layered, 
fiinctionally distinct entities, which allow easy access and addition of alternative 
protocols. This implies that a software developer could, for instance, leverage upon the 
physical and data link layers to build a different protocol architecture. 

For further details refer to the document. The AppleBus Protocol Architecture. An 
Introduction, and individual documents of each of the AppleBus protocols. Individual 
protocol specificatitms will be made available as they are finished, (see figure 2) 
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Figure 2. AppleBus Protocol Architecture 




Briefly, the architecture includes : 

Physical Layer 

The Physical layer encompasses the physical and electrical characteristics of 
AppleBus as described earlier in the Hardware section. 

Link Access Protocol (ABLAP) 

The AppleBus Link Access Protocol corresponds to the Data Link layer of the ISO-OSI 
reference model. The protocol, which must be common to all systems on the bus, provides 
"best effort" delivery of information between nodes. The ABLAP procedure manages the 
encapsulatimi and decapsulation of data in a fnme and then provides access to the bus 
for transmission and reception of frames. The format and interpretation of the data 
encapsulated by the frame is left to higher level protocols. Specifically, the LAP 
manages: 

1. Bus Access Control 

2. Node ID Assignment 

3. Node-to-Node Addressing Mechanism 

4. Packet Length and Integrity 

1. Bus Access Control 

All AppleBus nodes compete for use of the bus. It is the function of the LAP to 
resolve this contention, and provide fair access for all nodes. AppleBus uses an access 
discipline that is termed Carrier Sense, Multiple Access with Collision Avoidance 
(CSMA/CA). Carrier Sense means that a sending node flrst "senses* the line, and defers 
to an ongoing transmission. Collision avoidance means that the protocol attempts to 
minimize collisiixts. A collision occurs when two (or more) stations transmit frames at the 
same time. In the AppleBus CSMA/CA technique, all transmitters wait until the line is 
idle for a minimum time plus an additional time as determined by a generation of a 
(pseudo-) randmn number whose range is adjusted based upon perceived bus traffic. 
AppleBus hardware does not allow the actual detection of collisions. 



2. Node ID Assignment 

AppIeBus uses an 8-bit identification number for node addressing on the bus. 
AppleBus nodes have no permanent address or identification number conflgured into 
them. When a node is activated on an AppleBus, It makes a guess at Its node number, 
either by extracting its number from some form of long-term (parameter/disk) memory, or 
by generating a random number if it does not have non-volatile memory. The node then 
sends a special AppleBus ABLAP frame to its own address, and waits for an 
acknowledgement. If it receives an acknowledgement. It knows that the chosen node 
number is already in use. and repeats the process with a different guess until It 
succeeds. 

3. Node-to-Node Addressing Mechanism 

ABLAP is ultimately responsible for the destination and source node addresses 
encoded in the header portion of the outgoing frame. In addition to the ability to direct 
packets to a specific node on the AppleBus, ABLAP allows the broadcasting of packets to 
all nodes on the bus using address 'Hexadecimal FF*. 

4. Frame Length and Integrity 

Frame length may vary arbitrarily with a stipulated maximum. Individual messages 
are assembled into frames with an appended 16-bit Frame Check Sequence (PCS). The 
FCS is calculated using the standard CRC-16 polynmnial. Packets received with an 
invalid FCS are discarded by the receiving node. Furthermore, ABLAP may exploit a 
higher level length field to verify packet length. 

Datagram Delivery Protocol (DPP) 

At the next higher level of the architecture (the Network layer of the lSO-051 model) 
is the Datagram Delivery Protocol (DDP). While the ABLAP protocol provides 'best 
effort' node-to-node delivery of packets on a single AppleBus, the Datagram Delivery 
Protocol extends this mechanism to socket-to-socket delivery over an entire AppleBus 
internet. Sockets are logical entities within the nodes of a network. Detagrems, packets 
that are delivered as single, independent entities, are exchanged between sockets. 
Therefore, sockets may be visualized as simply the sources and destinations of 
datagrams. Sockets are said to be owned by socket clients, which are typically processes 




(or functions within processes), implemented in software in the node. 

AppleBus UiUrnets are formed by interconnecting up to 254 AppleBuses with 
intelligent nodes referred to as bridges or internet routers. [Bridges should not be 
confused with gateways. A gstewsy refers to a node separating and managing 
communication between different types of networks.] 

DDP uses the concept of network and socket numbers to provide an internet-wide 

addressing mechanism adequate for the delivery of datagrams among all sockets of an 

% 

internet. 

AppleBus Transaction Protocol (ATP) 

The AppleBus architecture includes several protocols at the next higher level above 
OOP (the transport layer of the ISO-OSI model). These protocols add different levels or 
types of functionality to the underlying datagram delivery service. An important example 
is the AppleBus Transaction Protocol which adds a measure of reliability by providing a 
loss-free transaction service between sockets. This allows exchanges between two 
socket clients (a requestor and a responder) in which one client requests the other to 
perform a particular task and report the result. The interaction, consisting of a request 
and a response, is termed a transaction. ATP allows for a transaction response that may 
be as large as 12 datagrams. ATP delivers each response message, correctly reassembling 
its component packets without gaps in the proper sequential order. 

This model fulfills the transport requirements for a wide variety of higher level 
services from simple devices through servers and other general networking services. 

Data Stream Protocol (DSP) 

This protocol is being proposed by Apple to provide a reliable two-way data stream 
service (also known as byte streams, virtual circuits, etc.) betwe«i a pair of sockets on 
an internet. The envisioned service provides for flow control and recovery from the 
familiar situations of packet loss, and duplicate or out-of-sequence packet reception. 
Such a service, layered on top of the DDP. would satisfy the transport service needs of 
applications exchanging sequences of data such as screen contents, keyboard input, etc. 


Name Binding Protocol (NBP) 

This session level protocol allows network users to employ character string names for 
socket clients end network services. The basic function of NBP is the translatim of a 
character string name into the internet socket address of the corresponding network 
entity. The protocol does no^ mandate the use of name servers. 

Routing Table Maintenance Protocol (RTMP) 

This transport level protocol allows bridges /internet routers to dynamically discover 
routes to the different networks (AppleBuses) in an internet. This information is 
maintained only in bridges. Ordinary AppleBus nodes employ a simple subset of RTMP for 
the purpose of discovering the number of the AppleBus to which they are connected and 
the node identification number of a bridge on that AppleBus. 

Higher Level Protocols 

Apple is developing other higher level protocols that exploit the services of the core 
protocols to build specific services. An important instance of this is the descripticxi of a 
general model of providing host to peripheral device access through AppleBus. 

Other examples are protocols corresponding to the various servers under 
development at Apple for file sharing, network printing, etc. 

These protocols will be published in due course for unrestricted use by developers. 
Summary 

The basic AppleBus product, incorporating hardware, protocols, and software 
described here, exceeds the requirements for its design center. In test cMiHgurations, 
AppleBus has performed with stability at offered loads of up to 100% channel capacity. It 
is without question the low-cost, highly extendable interconnect scheme Apple intended 
to design. 



The extremely low cost of AppleBus opens the psth to experimentstion by users end 
developers. Apple expects to recreste with AppleBus sn explosion of useful new 
products, ss already seen with the Apple I / and Macintosh. In addition to foreseeable, 
well-known network services, this activity will lead to unforeseen uses of the evolving 
technology of networking. It is. after all, the promise of increased human potential and 
productivity that underlies the concepts of personal computers and the networking of 
personal computers. 
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1.0 Introduction 

AppteGus is « serial interconnection system for all Afiple Computers and several 
futirt peripheral products. It provides a common, convenient, inesqiersive. 
e^qMnsion capability for computer products. In sunmary. AppleOus is a 
muiti-drop. balanced, transformer isofated. serial commutication system 
designed to connect 32 devices at 230.4 Kbaud (Ntr a total distance of to 
300 meters. 

2.0 References 

AppleBus Link Access Protocol, specification number 062~D214. 

EIA Standard RS-422. Electrical Characteristics of Balanced Voltage Digital 
Interface Circuits. 

Fairchild Semiconductor ‘Interface. Line Drivers and Receivers*. 1975. 

3 0 Summary of Featires and Performance 

* 32 total devices 

* Shielded, twisted pair, connector ized interconnection: easy user coni igurat ion. 
maximuT) total cable length of 300 meters 

■ 230.4 Kbaud communication. SOLC frame format. FMO modulation 

* Balanced signalling using standard RS-422 ckiver (26LS30) and receiver 
(26LS32) I.C.*s 

* Transformer isolation for excellent noise and static discharge immunity 

* Self-configiring, no user switches or action to identify devices 

* Passive drops, devices may be disconnected, and one may fail without 
distirbing communication 


||nppla computor inc. 


SIZE! 

il 

SCALE: 



DRAWING NLMBER 
062-0190-B 





4.Q Signing 

4.1 AppltBui dfvicn send and receive data over a single pair of wires 
connected to each device. T%vo connectors on each device allow the 
user to easily connect devices together by means of a simple cable 
(see Section S.O interconnection). Balanced, transformer coupled 
signalling is used to reduce both RFI and noise susceptibility. 

4.2 Each device has a single driver and receiver. The receivers are always 
connected to the system and pass all AppleBus data to the controller. 

Only one driver at a time is enabled. Software controls which device 
may transmit data (see Protocol Specification). The driver and receiver 
descriptions and specifications are given in the electrical section. 6.0. 

4.3 The signal on AppleBus is encoded with FMO (bi- phase space). This 
insures that clock information can be recovered at the receivers. In FMO. 
a transition occirs at the beginning of every bit cell. A *0* is represented 
by an additional transition at the center of the bit cell, and a *1* is 
represented by no transition at the center of the cell. 


12V MAX 
IV MIN ' 


4.34 US 


Figtf'e 4.1 FMO Coding (230.4 K baud \X) 

4 4 Synchronization time for the clock recovery system i$ provided by the 
transmission of 14 consecutive 1 bits directly preceding the data frame. 
Frame format is covered in the Protocol Specification. 
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5.0 Intercormection 

5.1 Af)pl»bus dwictt art conntcttd to tht AppItBut by a conntction moduli 

which contaim a transformtr« 06-9 comtctor at tht end of an 460 millimtttr 
cable, and two 3— pin miniature OIN connectors as shown in Figu’e 5.1. Each 
3 -pin comector hat a coupled switch. If both connectors are used, the 
^:witche$ are open, but if one of the conectors is not used, a 100 ohm 
termination resistor (R2) is connected across the line. The use of the connection 
module allows the 4pple6us device to be removed from the system by 
disconnecting it from the module without disttrbing the operation of the bus. 

R3 and R4 increase the noise immunity of the receivers, while RS and Cl 
isolate the frame grounds of the AppleBus devices md prevent ground loop 
currents. The resistor (R1) provides static drain for the cable shield to 
ground. 
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Figure 5.1 ^leBus Connection Module 
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b.2 Individual AppleBui devices are connected together by a twiste<L shielded pair 
cable. The cable is available in standard lengths with connectors on each endL or 
in ISO meter bulk rolls. The maximtan length of cable for the bus is limited to 
a total of 300 meters. 


Conductors: 

Shield: 

Impedance: 

Capacitance: 

Rise Time: 

Diameter: 


Cable Specification 

22 AWG stranded 17 ohm per 300 meters 
85% coverage braid 
78 ohm 

68 pF per meter 
1 75 ns 0 to 50% at 300 meters 
4.7 mm (0.185 inches) maximun 
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5 3 The AppteBm connector is a miniature 3 pin circular connector similar 
to Hosiden connector number TCP8030-01- 

Pin 1 Appi<*eus - Plus 
Pin 2 AppleBus - Minus 

Pin 3 Unused 
Shell Shield 

figure 5 2 Connector Pin Assigment (looking into connector) 

5.4 The interconnecting cable is wired 'one** to one* as shown belcM. 
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Figure 5.3 interconnecting Cable Connection 
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6 0 Electrical Specification 

6.1 The recommended ^iver is the 26LS3Q used with both >5V «td -SV as 
power supplies, and the mode control connected to give differential 
outputs (Mode voltage low). 

The outputs of the driver are coopled to the connector throu^ a 
"deglitch network* which consists of a T-network of two 20 to 30 ofvn 
resistors and a ISO to 300 picofarad capacitor. Use of the network gives 
two major acKantages. The first is that the high frequency components of 
the signal are attenuated both going onto and off of the c^le thus 
reducing RFI and also static susceptibility. The second ac^antage is that 
at least one driver on the network can fail without causing the network 
to fail (as long as it fails in one state and doesn't broadcast trash). 

Those who wish to use standard RS--422 specified components (power 
supplies of ’hS \^lts and ground may do so if the deglitch circuits are 
not used, but should be aware that the driver must drive a cable 
impedance of 39 ohms (middle of a 76 ofvn cable). 


^ ^ recei>^ is the 26LS32. Both inputs of the receiver are connected 
throu^ deglitch networks. 



6.3 The transformer is • 1:1 turns ratio transformer with tight coupling between 
primal^ and secondary, and electrostatic shielding to give excellent common 
mode isolation. 

The primary is wound as two windings of #32 AWG wire in series with one 
wound below the secondary and one above it. 

CUT TABx. 


Dimensions in 
Inches 


P.C. PATTERN 


-Li i , 

0.280 0 0.046 O I 

--pO (6) - 


Specifications: 

Core Material: 

Bobbin: 

Retaining Clip: 
Magnetizing inductance: 
Leakage Inductance: 
Capacitance: 


Siemens B656S1-1<000-R030 (or equivalent) 
Siemens 665652 '-PC IX (or equivalent) 
Siemens 665653 -T (or equivalent) 

20 mH minimum 
15 uH max 

5 pF max (^im^ to secondary with 
electrostatic shield and core guarded) 


Figure 6.2 Transformer Specification 
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6.4 Each end of the cable must be terminated. The AppleBue comection module is 
designed such that a 10Q ohm resistor is connected across the line if one of the 
two connectors is not used. A 100 ohm resistor is used even thou^ the 
characteristic impedance of the line is 78 ohms because it gives adequate 
termination and minimizes resistive losses. 

6.5 The cable shield should be grounded to Earth ground (frame ground) at each 
AppleBus device. This ground is necessary to prevent excessive RFI. A resistor 
and capacitor are included in each connection module to isolate the cable shield 
from the ground connection at 60 Hz while offering a low impedance connection 
to high frequency noise. This connection scheme allows grotfid connection for 
RFI purposes without risking high currents flowing in the cable due to differing 
ground potentials. In the U.S., the ^een wire available in most outlets is 
suitable for frame grounding. 
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7.Q Documentation 

The foliating is a list of ail AfpleBus hardware drawings. 


Drawing Description 

Drawing Number 

AppieBus Connection h^loduie Cover (Top) 

81S-Q839 

AppieBus Connection Module Cover (Bottom) 

815-0838 

AppieBus Cable Extender (Coupler) 

519-0300 

AppieBus Cable with Molded Plugs 

590-025X 

D6~9 Connection Cable Assembly 

590-0254 

06-25 Connection Cable Assembly 

590-0253 

AppieBus Board Film Artwork 

820-0135 

AppieBus Connection Module FCC Label 

825-1008 
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1.0 Oncriptiai 

The AppIcBui traraformcr h uKd In the AppIcBm connection module to Qh« 
isolation be t wee n the AfipIcBui cable and latits %id>ich are connected to the cable. 

The transformer it a 1:1 turns ratio transformer with ti^t coi 4 >ling betv^een 
primary and sccondvy, and clectrastatic shielding to give excellent common mode 
isolation. 

The prinvary It woieid as two windings of #32 AWG wire in series with one vnwid 
below the secondary and one abo^ it. The secondary it a single continuoui winding of 
#32 wire. 


2.0 Efwironmental ^ 

The tran s former Ml operate p-operly and meet its specifications infer the 
foilowing environmental oonditions: 

Operating Temperature: 0 to 70 degrees C 

Storage Temperature: *-40 to 70 degrees C 

Relative Hienidity: S to 9S% 

Altitude: 0 to 4572 inetert 

In additiorw the transformer must meet the Apple Computer shock and vibration 
requirements vihile mounted on a printed circuit board and tested to Apple 
spccifieotion nwnber 062-0006. 


3.0 MrcbeninI Strength and Wo rtonanship 

The transformer winding assembly, pins, mounting plate, core, and clamp shall be 
securely mounted and rigid with respect to each other. 

The pins must be easily solderdble; solderability mist meet EIA specification 
RS-178B. 

All eomporvfrts shall be free of laidue mechanical stresses. 


4.0 Identification M arking s 

The trantlormer shall be marked with the manufacturer’s nsme or identification 


raanber. dMe of manufacture, country of origiit manufacturer’s pvt rambtr. snd the 
Apple part menber. The markingi shell be dearly legible aftv t^^ical assembly, 
wave— soldering end cleaning processes end after eiqxmre to the dbove mentioned 
environmental extremas. The markingi ntay be placed in any convenient and visible 
location on the tr a n s former. 
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S.Q Eltctrleal Spcclficatiom 


Core Miter lal: Siimini B65651-K000-R030 (or C9ulvilfnt) 

Bobbin: Sicmint B6S6S2~PC1«L (or equivilent) 

Rttaining Clip: Siimm B656S3->T (or iquivilmt) 

Mignitixini Inductver. 20 mH minimum 
Leakage Inductmoe: 19 uH mac ^ 

Cipacitaioe: 9 pF mac (primary to tacondary with 

electroatatic ahield and core guarded) 

Tirna Ratioe 1:1 acorate to the neaect 1/2 ttm 

Hi Pot: From W2 to core, ahield and primary 1000 VOC for 

one minute with no tigiif leant leakage orrent. 
















AppleBus 

Link Access Protocol 
Specification 

Version 1.0 


Apple Computer, Inc. 
May, 1984 



DBCLADiER 


l>iis specification includes subject imtter vAich mgr relate to patents of Apple 
Computer. No license under any sudh patents is granted bgr implication or otherwise as a 
result of publication of this specification. Applicable licenses may be obtained from 
i^ple Oonputer. 

This specification is furnished by Apple Computer for informational purposes only. 
Apple Computer. does not vArrant or represent that this speclficatian or argr products 
made in oenformance with it work in the intended manner or to be compatible with other 
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raKFACE 

This document oortUins the specification of the AppleBus Link Access Prctoool, * 
netvcrk aooess protocol developed by Apple Oomputer. This document is intended as a 
design reference document. The document's structure is based an The Ethernet Data Link 
Physical Layer Specifications. Version 2.0, November, 1962. Die AppleBus Link 
Access Protocol itself is significantly different from the Ethernet Data Link Protocol. An 
Overview of AppleBus and the The AppleBus Protocol Architecture, An Introduction are 
separate documents that include introductory descriptions of the AppleBus Link Access 
Protocol. 

This specification contains four sections that describe the AppleBus Link Access 
Protocol from several aspects. Sections I» end II provxle en overviev of AppleBus end 
the functional modal of the AppleBus architecture. Section ID describes alemants of the 
AppleBus Link Access Protocol, Including the frame format, frame transmission, and 
frame reception. Section IV contains a procedural model of the Link Access Protocol as 
v»U as the interfaces to the Physical and Network Layers. 

Ksaders looking for an overall understax^ing of the the AppleBus Link Access Protocol 
should read the first two sections, lir^lementors of the Link Access Protocol will find 
that sections m and IV contain the details of the specification. 

Hetotian 

Three different numerical representations wQl be used in this document: 

Sbb...b for Binary numbers, ( b ■ 0 or 1 > 

$hh for hexadecimal numbers, ( h ■ 0, 1, ... , 9, A, B, ... , F ) 
numbers nn...n with no prefix for decimal nwrbers ( n ■ 0, 1, ..., 9 ). 


The term Aodb is tised throughout this specification to refer to any computer, peripheral 
device, server, etc., that is attached to and communicates over the shared medium of 
AppleBus. Other c o mm o nljrused synonymous terms are sUt/dnanA host 

InsJemgrtation 

This document is a specification of the function, fernw and proce s s es of the AppleBus 
Link Aooass Protocol. Although frequent reference is made to aspects of specific 
InplerrenUtions of the protocol on various Apple oorrputers, this is merely for the 
purpos e of Qliistration. Ihere is no implieatian that the mentioned hardv«re or softwe 
configurations are required by this protocol specification. 
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L htroduetkn 


Ap^Bus is A STsiem designed to function in throe mejer configurations: as a small 
work-araa intaroonnect system, as a tributary to larger networks, and in Hs most 
elemental form, as a peripheral bus between an Apple computer and Hs dedicated 
peripheral devices. 

As a stand-alone work-area network, AppleBus provides communication and resource 
during among up to 32 computers, servers, disks, printers, modems, and other 
peripherals. More importantly, AppleBus supports a wide variety of forthcomii^ 
services such as shared files, electronic mall, and communication %dth computers and 
resources on othar networks. Further. AppleBus has been des^ned to elkw Hs 
inoorporation, through bridging devices, into larger networks. 

%ihen functioning as a peripheral bus, AppleBus in effect implements the concept of skis 
by providing an external serial bus for the connection of a variety of peripheral devicas. 

Applebus is designed to fH the needs of the individuel us«r vdu wldies to extend his 
mezimum number of directly-attached paripherels, and provide for the sharing 
requirements of e small cluster of computers. Careful attention has also bem paid to 
businesses, vhere work-area networks feed large backbone networks and corporate 
communication implies a mixtxire of networks and technologies. The design goals of 
AppleBus cm be sumvmrixed as: kw cost, easy to install, easy to extend, end an ^en 
system architecture. 

^pleBus access hardware is built into Macintosh and Lise systems, and is essentially 
fkee for these systems. The Shielded, twisted-pair cable used to form the bus. end Hs 
as s ociat e d cables and conneetors, tarng the actual pe r-n o da connect oost to only about 
$ 25 . 

Electrically, AppteBus has bean designed vdth passive Ctrensformer) coupling of nodes to 
a trunk cable, wHh simpk, selfHerminating miniature DIN ccnne e tors. No special 
installation is necessary, and computers, peripherals, or servers may be easily relocated 
cr added. The actual connection of a device to AppleBus is simpler than hooking stereo 
speakers to a Tii-f i** system. 
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.1^ i^plcBus ni^olooQls Fkckatfe supports s range of oonfigurations from simple 
Hedicsted device aitechment through intemetworking. With the same soft^awne. AppleBus 
may be extended through AppleBus bridges to other AppleBuses, and through gaiev«ys to 
eommunications services and other netvMrks (local cr krvg-haul). 

Apple has developed a suite ot protocols for AppleBus which provide functionality 
oorrtspending to the various layers of the Intcmaiional Standards Organization (ISO} 
Open Syvtams Interconnection (061) raferanoe modal (sea Figura 1). FTotocols at tha 
B0-06I layers 1 thorough 5 (Physical, Data Link, Network, Tr an sport, and Session) form 

le 

the core of the AppleBus Protocol Architecture. The use of leyaring allows developars to 
design new functions and applications for AppleBus. Throughout the development of 
AppleBus. Apple will make all technical documentation completely public. 


PataRaie t 230.4 Kilobits per s econd 
Meximum Node Separation ; 300 meters 
Naximum Number of Nodes ; 32 

KedJujTu Shielded, twisted-pair cable, baseband signalling 
Topology ; Linear, non -branching bus 


Link Oontrol Procedure ; Fully distributed peer protocol, %^th statistical 

contention resolutiori (CSNA/CA) 

Meeaage Rnotocol ; Variable eise frames, *naest effori" delivery. 
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Application 



ngu9 L ^leeus Pioioooi Arcnueciure 
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L2 HMftKJire 

AppkBus «t the Ptkysieel level hes a bus top^ogy consisting of a linear trunk cable with 
intervening oonnection modules to %dvich node s attach via a short drop cable. Electrically 
and mechanically, i^pUBus is a multi-drop, balanced, transformer-isolated, serial 
communicatiQns system for up to 32 nodes. T)m raw data rate is 230.4 Kilobits per second 
ovar a distance of 300 meters. 

Bata packets are transmitted as frames using an HDLC/SBLC formal; the frames bits are 
encoded using FM-0. FM-0 is a bit encoding technique that provides self-clocking. 
Balanced signalling is echievad using RS-422 driver end receiver ICs in each of the 
attached devices. The trensformer provides ground isolation as wall as protecticn from 
static discharge. Since a node is passively connected to the trunk cable vie a drop cable, 
a device may fail %dthout disturbing oonvmnicatiQns. Nodes may be added and ramoved 
fbem the bus with only n^nor disruption of servioe. 

Sinoe and-user msteUetion is assumed, essennblad cables be sold in standard 2, 6, and 
IS meter lengths with rroldsd .’rir.kturs DIN connectors. The trunk cable connects to an 
AppkBus oonnection moduk. The oonneeticn moduk is a smell plastic ease (3"x Z”x 1") 
containing a transformer, resistive and capacitive circuits for noise immunity, and two 
3-pin minialure DIN connectors with switches to a 100 ohm termineting resistor. 

Attacked to this plastic ease is an 16-ineh "drop cabk" %4iich terminates et the node with 
either a DB-9 or DB-2S connector. The trunk cable is shielded, twisted-pair cable 
CBakkn 9272 or equivalent^. 

For detailed hardware inforrmtkn, refer to AppkBus Kleetrioel/Heehenieal Spaeificeiian. 
WTeh.1964 CAppk Doe Nix 062-0190-AD. 


L.3. Rreorrik and Boftwere 


Urtderlying the use of AppkBus is e specific set of protocols, or communication *Vules". 
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These protocols oarrespond to the ISO-OSI layers 1 throu^ 5 Cl^hysical, Data Link, 
Network, TWnspoK. and Session). 

While Apple reoommends the use ot these protonnls, oonvnunicalion over AppleBus is not 
dependent cn their exclusive use. The protocols are laa^red. functionally distinct 
entities, which allow easy aooess and addition of alternative proieools. This intplies that 
a software devtioper could, for instarvoe, leverage upon the j^yysieal and data link layers 
to buQd a different protoool ar^heetxBe. 

For further details refer to the document. The AypleBus PTetocel Arddtecture. An 
tetroduelicn. and individual documents on each of the AppleBus protocols. Ftotoaol 
specifications will be made avaOahle as they are completed. 

Briefly, the three layers of the ar^itecture that are relevant to this specification 
include: 


The Fhysicel layer encompasses the physical and electrical diaracteristies of AppleBus 
as dasoribed earlier in the Hardware section. 

T.fcie Protocol 

The 4pfJ6BU9LitJtAoaBssAvioaat(,ABLAF') corresponds to the Data Link layer of the 
SO-OSI reference model. This protocol, which must be c o im an to all systems on the bus, 
provides Hbest efforl" delivery at data packets between nodes. The ABLAP manaKes the 
Micapsulation and decapsulation of data in an ABLAP/twmvA then provides access to 
the bus for transmisaien and reoepticn of frames. The formal and interpretation ot the 
data «Mapsulated by the frame is left to higher levd protocols. Detafled description of 
ABLAP function are in section H of this doeuimni. Xn sunvnary, ths LAP manages: 

1. Bus Access Control 

All AppleBus nodes oorrpsta for use of the bus. It is the function at ABLAP to 
resolve this contention, and provide fair access for all nodes. AppleBus uses an access 
discipline that is termed CkrriBr Stnae, Multiple Aoaaea Obllhian AeoiMnae 

CeSMA/XSAJi Canrier Sense means that a serving node first "senses" the line, and defers 
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to ongoing transmission. CbUIsJon sicubhoenfmans that tha protocol attempts to minimise 
collisions. A ccdlir Jen occurs when tv» (or more) nodes transmit frames at the same time. 
In the AppleBus CSMA/CA technique, all transmitters wait until the line is idle for a 
minimum time plus an additional time as determined by a generation of a (pseudo-) random 
number %d»se range is adjusted based upon peroehrad bus traffic. ABLAP does not 
require hardware for the actual detection of collisions. 

2. Mode ID Assignment 

AppleBus uses an 8-bH identification number (Aodb s d± yts s or neds ID") for node 

a 

addressing on the bus. AppleBus nodes have no permanent address or identification 
number configured into them. Vfhen a node is activated on an AppleBus. H makes a guess 
ai its node numberi either by extracting its number fSrom soma f or m of long-iazm 
(parameter/disk) memory, or by generating a random number. The node then sends a 
speciel ABLAP enquiry frame to this guessed address, and waits for an acknovdedgement. 
If tt receives an acknoaAedgement, it knows that the chosen node number is alraadtsf in 
use, and repaate the process with a different guess unt& H succeeds (no 
acknowledgement received after repeated transmission of the special enquiry frame). 

3. Wode-to-Hode Addressing Mechanism 

ABLAP is ultimately responsible for the destination and source node addresses encoded in 
the header portion of a frame. In addHion to the abQHy to direct packets to a specific 
node on the AppleBus, ABLAP allows the broadcasting of packets to all nodes on the bus 
using destination address SIT. 

4. frame Length and Integrity 

frame luvgth may vary arbitrarDy with a stipulated maximum of 600 data bytes. This data 
is assambled into frames with a thrae- b yta ABLAP header and an appended 16-bH Jhvne 
CBsek AquaneeCPCS). The PCS b calculated using the standard CRC-CCiTT 
polynomial. Packets received with an invidid PCS are discarded by the receiving node. 

ITkis document provides a precise specification of the IDeta Link la^r of the AppleBus 
architecture. It does not specify the higher level protocols required to complete a 
network architecture, nor does H detail the physical interface to the oomnunication 
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madhira Tht higher Icvti protocols are «zp«ct«d to provide error recovery, flow oontrol. 
end end-io-and trensport of user date, as well as support for application services. 

The priiisry objectiv* of this specification is to ensure ooinpatibilHy among various 
AppkBus implementations. While different higher level protocols be implemented on 
AppleBus, the enforoement of a unique LbOc Access Protocol wOl guarentee standard 
access to the network that is both fair and stable. 
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n. g\mctioBal Modri ci the AppleBus lAk 




The AppleBus Link Access Protocol p e r fern a the functiens c o rpe sp onding to those of the 
OttU Link Leyer of the 190-081 reference model. ABLAP elso performs the addition 
function of dynemic node address assignment. The foUo^>nng functional model describes 
the genial oonoepts of the protocol. 


Che of major architectural features of AppleBus is the use of layering. Layering lends 
clarity to the design by defining and interrelating functionally distinct protoools. Each 
layer of the protocol architecture builds upon the services of lower layers and Hself 
provides services to higher leyers. In the specific ease of the AppleBus Link Access 
Pboioool. the Physical layer consists of the tiw^nusskninadium amd the associated 
electrical aignalling facilities used by ABLAP to transfer data frames. ABLAP in turn 
provides the Network layer protoools (the ABLAP cHanf) with a "best effort". 
and ' - ft e e , node -to-nede delivery of dela packata. 

IL2. Physical Leaer 

The Physical layer of AppleBus is a 230.4 Kilobit par aeoond channel through a shielded, 
twisted pair cable. Ihe channel is driven in oonformanoe %^Hh EIA Standard RS-422 
balanced voltage specifications. The Physical layer performs the functions of bit 
anooding/decoding. synchronization, bit transmissionAeception. and carrier sense. The 
layered arehitacture of AppleBus allows for the R\ysical layer to be replaced by another 
medium aa long aa these functions are i^widad arki the intarfaoa between the Physical 
and Seta Link Is maintained the same. An explanation of each of the functions performed 
by the Physical lajmr it summarized below. The details of the AppleBus Physical layer are 
in the AppleBus Hechanical/Dectricel Specification referred to earlier. 
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Bits src snooded xising s self-clocking technique known es fM-0 Cbi-phese speoe). In 
FM-0, eei^ bH cell CnomineUy, 4.34 ^sec) oonteins a transition at its end, thus providiz>g 

timing mfcrmation. Zeros CO's) are enooded by adding an additional transHkn at n^-oeU 
Csee Figure Z). 
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FJg^MBZ FM-0 Encoding 


At the beginning of a ftreme ABLAP transmits a sjnehrenigUian putm. This is a transition 
on the bus. followed by an idle period greeter then two bH-tImes. Ihe synchronization 
pulse is obtained by momentarily enabling the line driver for at least one bH time, before 
disabling H. This causes a transHion %rfhich %/ill be taken as a dock by all reoeivars on 
the APpleBus. Hewavar. sinoe H is followed by an idle period of sufficient levgth, a 
Missing Clock is detected by the reoeivars. The Missing Qoek allows transmitters to 
syndttxniae their access to the lira. 


The use of the EIA RS-422 signalling standard for transmission end reception over 
AppleBus provides significantly higher data rates over longer distances than %idth the 
EIA RS-232C Standard. AppleBus uses differential, balanoad voltage signalling at 
230.4 Kilobits per second over a maximum distance of 300 meters. The balanced 
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oonf iguration providts better iaoletian from ground noiae currents and is net susceptible 
to fluctuating volti^ potentials between system grourrds or c o mmon mode electromagrwtic 
interference (EMI). 


CerriBT Sense 

The Physical l^er provides en indication to the Link Access Protocol vd«en activity is 
sensed on the cable. For instance, on the Macintosh, carrier is sensed v4wn the start of a 
valid ftrame is detected by the Zilog^ 8S30 Serial Oacimmicatkns Ocntroiler {.MlimtMH 
equals saro). 

n.3. PsULh^kUser 

The AppleSus Link Access Protocol is the key mechenism allowing i^pleBus nodes to 
tftare the communication medium. It performs the functions of uniquely addressing each 
physic^ node en AppleBus, encapsulation and decapsulation of user data wHhin en 
ABtAFitwm, transparent transmission and reception of the frame through the physical 
medium, mei^egement of acatss to the j^\ysicel medhirrw and detection of transmission 


Each node on an AppleBus has a unique 8-bit address, which is also known as the Jtedie 
itanUfkrCnoOtt ID). This a ddre ss is used to identify the source end destination of each 
ABLAP frame. Unlike other networks that use fixed, universally unique addresses, 
AppleBus uses a dynamic node address assignment scheme. Thus, AppleBus node 
addresses are unique only wHhin their local bus and may ^\angt ever tirm. 

Ihe 8-bit AppleBus Destination address is used to "filter" frames at the data link layer. 
IVames w h os e destination ed di ^ aa does not match the receiving node’s ad d re ss art not 
acoeptad by that node. The address 2SS C$FD has a special signifanoe. IVames received 
vdth destination address oqxial to this valm are eooeptsd by all nodes. This permits the 
"broadcasting’* of data packets to ell nodes of an AppleBus. It is important to note that 
the node a ddres a scro (0) is not allrwisd and is traated as ’Nmknown". 

Data Encapsuktien/Dacapsulation 
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Osta •ncapifulat ion/d»c«p«ulat>on is tht ftntrsl imthod uind by th* ApplsBus Protocol 
Architecture for novmg user mformetion up or down throu^ the protocol layers. A unii 
of user infonralion is enclosed ay a layer-specific header and/or trailer as H moves 
throu^ each layer from a user application down to the data link layer. In the ease of 
ABLAP, a siraairhle, an ABLAP header and trmiler/poatarrfcle cndose the data pa ss ed fron- 
the next higher layer Cnetwork). The oorrespondind protocol lager et the receivini end 
examines and remove s the layer- s pe c ific protocol information as user information moves 
up throu^ the leyers to the receiving appliealion. 


AppleBus uses a bit-oriented data link protocol for data transmission end reception. 
Uhlike byte-criented protocols, a bit-orkntod protocal permits the use of all bit patterns 
within the firame. The fbame delimiter for ABLAP is called a fLAO. A flag is the 
distinguished bit sequence tOllilllO ($7E). TVpieally, flags are generated by 
Charduare) transmitters at the beginning ind end of frames and used by Cherdwere) 
receivars to detect frame boundaries. 

to order for the date link protocol to transmit all bH patterns vdthin a frame the pretoool 
mast insure date transperen^. This is provided by e technique lotown as *hit stuff 
ABLAP guerentaee that date sent on the bus oontains no sequences of more than f iva 
oonsecutiva l*s. It does this by inserting a 0 after each string of five consecutiva I’s 
detected in the user data stream. Areoeiving ABLAP performs the inverse ^Mratioru 
**stripping** a 0 %dikh foUows five oonsecutiva l*s. 


AppleBus is a tfured, oonirumcation medium and so requires that access to the medium 
be managed. This access imnagement is performed by the ABLAP protocol. ABLAP \aaes a 
contwition resolutian method kxwwn as C^nrmr S mm Aoeuas OaUmkn 

ilt«ubhrMa(CSMA/CA) for link aeoem menagement. GSMA/CA uses the Carrier Sense 
signal ^xrvided by the Physical Layer to determine if the ehannd is bu^ end, if so, waits 
for a random period. A frame dialogue is used to implement a ooUision avoidance scheme. 
This scheme is discussed in detail in section 1V.2. 
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Prt#etian 


Because oonrrunicalion chaiv«ls are error prone, an important function of the data link 
layer is to assure correct reception of data. ABLAP uses a frame check sequence known 
as Cyclic Redundancy Check CCRC) to block check the data frame. ABLAP uses the 
standard CRC-CCITT polynomial to compute the PCS by performing a polynomial division 
on the data frame. Frames detected %idth an invalid FCS are discarded by the receiving 


ImplefTantatkm Mote 

It should be noted that FLAG generation and recognition, node a d di 'e ss reoogniticn, 
bH-stuffing (and stripping) and FCS generation/validatian will typically be done by 
interface hardware. Figure 3 Illustrates the relationship betwam the lowest tvxo layers 
physical and Link Acocss) of the AppleBus FTotocol Architecture and a typical 
implementation (the Macintosh) in herdwere and software. 
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m t.inV 




The foUowir^ Mctions describe the mjar fsatures of the AppleBus Link Access Protocol. 
These include s dynemic node number assignment mechenisirw the fHtme format, and frame 
transmission and reception processes. 

yni- l>m ande tfede Huwi» Assiflnww 

AppleBus does not require that a node's address be l !soorded/ccnfigurad in H 
permanently. *n«e primary motivation for this feature is that vAten a node is moved 
between AppleBuses, it is possible that its old node number conflicts with one already in 
use on the new bus. Ifence. H will have to acquire a new node numbor. 

The procedure. fqr determining a node number is as follows: 

Vhm a node first becomes active. H makes a guess at its node number. This guess mey be 
, provided by some sort of long-term memory (e.g.. peremeter mem ory) or may be generated 
•eeh time by some psuedo random mechanism (e.g., the low-order bits of some timer, 
etc.). 

Bx any ease, the new node must then verify thet this guessed number is not alreedy in use 
by some other node on that AppleBus. This is done by repeatedly sending out a special 
directed ABLAP ^iq^urjr oentrei the guessed node address. If the guessed 

eddress is in use, then the oorresponding node will, upon receiving the enquiry respond 
vdth en ASLAP Aeknoiuie4gs centrof/hum The reception of this frame indicates thet the 
guessed number is elreedy in use end e new guess must be generated. 

Repeated transmission of Enquiry frames is used to eooount for ceses vdxere e node using 
the guessed eddress might currently be busy, end thus miss an Enquiry frame. 

Node addresses are divided into two classes; survor nedb edUhasaerand uaar/Hdb 
The range of addresses for user nodes is 1..127 ($01..$7F); the ran^ for 
■■Tver nodes is 12B..2S4 ($80..$FE), with $00 reserved for "unknown** and $TF reserved 
for broadcast. 
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Dm addk^MS spaot is splH into ivrfo parts dut to tha fact that soma nodas trmy for 
axtMktod pniods of time disable recaption from AppkBus Cfcr instanoe, if they are in the 
middle of e davioa-intansive oparation. such as disk access or transferring a bitmap 
doeumMtt to e la s e r printing device). Sudt a node wOl not respond to another node's 
enquiry frwnes. This could lead to tvo node s acquiring tha same node address. 

It is extremely important that no node acquire the same address as an already-functioning 
server node since this would disrupt service not only for the oonllieting nodes but also 
for other usurs of the snrver. ^ exduding user Cno n s erver) nodes from the address 
range used by servers tha possibility of user nbdas (swhdMd on and off with greater 
frequency) confliciting %dth servers is ^iminatad. 

Within tha user node address range, verifioatian can be dona more expeditiously (fewer 
retransirtoions of the Enquiry fhame) to decrease the initialization time for sud\ nodes. 

A more thcrpugh and extended address assi^unent s c h eme is used by servers, i.e they 
taka extra time during the address verification process to «vsure that, once dwsen, they 
%dn ba isiique on tha /^plaBus. This is not datrimantal to a sarver's aeration since 
sudi nodes are rarely switched on or off. 

If, during normal operation after acquiring Hs address, a node detects the use of the same 
address by some other node (a.g., it receives a Oear-to-Sand fhame with souroe address 
tha same as Hs o%m address), then the ABLAP driver ^wuld set a flag to indksata an 
address conflict error condition to Hs dientCs). Reooveiy fhom this condHkn, if desired, 
is the responsibility of higher level protocols. 


Tha basic unH of ABLAP transmission is a Figura 4). Prkr to transn^ting tha 

frame, ABLAP sands out a synchronization pulse foUowad by a /hMspnaaoifrle consisting 
of two or more flag bytes CkOUimO). Tha ftrama is followed by a iFwni 
rrwtmiM tmily ciansisting of a flag byte (IDIUIUO) and an abort sequanoa (seven or 
more IbHs). 


IS 












The ABLAP ftem itself consists of « three byte XflL4P Ae edb r (the destinetion node 
address, the source node address, a one byte LAPtjpt /SeU') fdkwed by a variable 
length data field CO to 600 bytes^. and a 16-bit frame check sequence. 


The Destinatian node address (6 bits) specifies the address of the node for vdtich the 
fbaim is intended. 


The Source node address (8 bits) specifies the address of the node sending the frame. 

LAP Type yield 

the LAPfypiFUd (8 bits) is used to specify the type of the frame. Values 128 to 255 
C$80 to $ID are used by ABLAP for Hs own control frames. ABLAP frames do not include 
a data field. The different ABLAP control frames are as follows: 

* lapDIQ CLAP type « $81): This identifies the ABLAP Enquiry frame type used ^ the 

dynamic node addre ss assignment meehanismt 

• lapACX CLAP type ■ $82): A node receiving a lapBNQ frame must send a lapACK 

CABLAP Acknowledge) frame in response; 

* lapRTS CLAP type ■ $84): This frame is used as part of the 3-way handshake to 

t ra n s m i t data packets. It notifies the destinatian that the transmitter wishes 
to send a packet to H. The destination must r es pond vHh eithur a lapCTSi 

• lapCTS CLAP type • $85): This frame is sent by a destinatian node in response to a 

lapRTS. It bndicates the willingness of the receiver to accept a data packet. 

ABLAP control frames CLAP type in the range $80 to $FT) received with a type field othn* 
than those listed above are simply discarded. 

LAP type field values 1 to 127 C$01 to $7F) are usad in AKAP frames carrying dknt data. 
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Jgi such Aramn, the type field pUys the roile of an identifier of the dient’s protoool type. 
This allows the simjltaneous use of ABLAP by several netvierk level protocols (crucial to 
tnaintaining an open systens architeeture^. The ABLAP inplementation in a reoehrintf 
node uses the value of this tjrpe field to determine the client to v^«om the Aname*s data 
mast be deltverad. This client in turn uses the LAP type field val\je to decide how to 
interpret this data (format of the data* higher level protoool header. eicO* 

As en example, the Datagram protocol of Figure 1 specified by Apple (celled the Datagram 
Delivery PtotoeoO uses LAP type field values of 1 and 2. (See the already referanoad 
document on the AppleBus Pr^oool Archheetura). 

ABLAP transmits and receives data packets on behalf of Hs clients. The format and 
interpretation of packets is defined by higher level protocols. Client data is sent by 
ABLAP by encapsulating it into an ABCAFIkit trtm (LAP type field • $01 to $7F). 
data f iald oontains a sequence of up to $00 octets. It Should be noied that the length 
bits of client data in a frame must be an integral nultipla of 8. 

FSame Check Sequence Field 

The 1$*^H ftaime check sequence ^CS) is confuted as a function of the contents of the 
source address, destination address, LAP type, and data fields. The anooding of 
CRC*CCITT is defined in terms of the standard generating polynomial: 

0(x) ■ x^^*x^*x^*xl 

The CRC-C^TT fkame cheek sequence value oorrespending to a given frame is 
calculated based on the following polynomiel division identity: 

- Q(x) ♦ R(x2 
0(x) G(x) 

vihere: 


N(x) « binary polynomiel (corresponding to the frame after complementing 
its first 1$ bits); 
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R(x) ■ rtimind«r after dividing N(x) bgr the generating potyrKimial (Hs 
coafficientx are the bits of the FCS). 

The lnf>lementation of the CRC for the FCS fieid» at the transmitter, computes the CRC 
Starting t^th the first bit of the destination address folkanng the opening flag and 
stcppbig at the end of data fidd. The FCS field at this point is an biversion, or 
ones-oomplement, of the transmitter's remainder. The result of a ooereetly received 
transmisslan Is a constant: tDOOmoiOOOOmi (x^..x*). 

bt the SOLC implementation of CRC, a modified polynondal expression (modulo 2> of the 
truxemitted data to be checked is divided bgr t& generating polynondal, x^^ *■ x^^ x^ 1. 
Integer quotient digits are ignored, and the transmitter sends the complement of the 
resulting remainder value as the FCS. 

eddHkn to the division of the binery value of the data by the generating polynomiel to 
generate the remainder for checking, the fhUowipg manipulatians occur: 

1. The dividend Is Initial^ preset to aH i's. This edds the binary value of 
^ ^asel bits to thal at the data bUs. 

2. The transrr^ter's rtmaind^ is mverted bH*i^r^it (FCS field) as it Is 
sent to the receiver. The high**or^r bit of the FCS field is transmitted 

first (xis xo>. 

S. The reoehrer includes the FCS field as part of its dividend. Continued 
computation raises the valiw of the dividend polynomial by the factor 

x^. Since the dividend and remainder at the receiver is equal to that at 
the trenendttcr at the beginning of the FCS f idd, the ramainder at the 
receiver et the end of the FCS field is a constant that is characteristic 
of the dhrlsar. 

K the receiver oompulatian does not yield the constant. SOOOlUOlOOOOUli. it Is assumed 
that the frame vms received In The entke frame is suspect and discarded. 
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TVmiwc Sne LiwiUtiera 


Sinoe the ABLAP heeder consists of 3 octets and the data field has 0 to $00 octets, the 
smallest valid Orame Cnot including the PCS) is be 3 octets long, while the largest is 603 
octets long. 

1IL3. fhame Tr» w i raBs i c n 

ABLAP transmits client data in ABLAP data frames using a special dialogue involving one 
or more ABLAP oontrd frames follwad by an ABLAP data fnme. The exact form of the 
dialogue depends on the destiruition of the frame. On this basis ABLAP distinguishes two 
kinds of frames: Undedand Armdiamrl 

A directed packet is one whose destination address is a sii\gle node; a broadcast packet 
is iniended to be reoehred by all nodes. 

nte purpose of the dialogue mentioimd above is to control the access to the shared bus in 
an orderly fashion that reduces the probability of a ooUision. This is based on a 
C5MA/GA ta^mique. 

The dialogues most be separated by a minirrum Intar-Dialog Gap (XDC) of 400 usee.; the 
different frames of a single dialog nust follow one another with a maximum Inter-Frame 
Gap (VC) of 200 lisec. 

The frame transmission procedure is described sepantely for directed and for broadcast 
frames. 

Consider the ease of a directed data frame (see Figure $(a». The transmitting node uses 
the physical layer's ability to sense if the line is in use. If the line is busy the node vaiits 
until it becomes idle (the node is said to dMr*). Upon sensing an idle line, the 
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tnnsmitttf* %«Hs for « tira aquid to the rrmvmm IXXS plus e rsndofrily gencrmted enount. 
During this the tnnsmitter continues to mcnitor the line. If the line renmins kOe 

throughout this mH period* then H sends sn ABLAP lepRTS fkvne to the intended 
receiver of the dele fheme. The receiver nust vdthin the imximum IFO return e lepCTS 
fireme to the trensmitting node. Upon receiving this firefne* the trensinitter must within 
the meximum IPG send out the dele fheme. 

The puiiwjse of this elgorithni is twofold: (1) to restrict the periods in vd\i^ ooDisions 
ere highly Ukdy Cthis is during the lepRTS-lepCTS exchenge), end (Z) to spreed out in 
time severel transnutters vAhing tar the line to become idle. The lepRTS-lepCTS 
exdtenge. if successfully completed signif ies thel e coUiskn did not occur, and that all 
intending transmitters have heard of the coming date ftsme transmission and are 
deferringA^ing. 

If in fact e coUision does occur during tte lepRTS'lapCTS exchange, e lepCTS will not be 
received, and the sending node wu thun heegcdTand retry. The sending node is said to 
presume a ooQisian. 

Tha rangt of the random wait time is adjusted if su^ e collision is detected, bn fact, thL 
adjustment or back off is done using a linear back eff algorithm that dynamically modifies 
this range in response to recent traffic history. The idea is that if coUisions have been 
presumed for recently sent peckets, this signifies heavier Iceding end higher oontention 
for the bus. Thentherandomwait sdMuld be generated e»v«* a larger range, thus 
spreads^ out (in time) the different oontenders for the line. 

Two factors are used for adjusting the range: (a) the number of times the node had to 
defer, and (b) the number of tliras tt had to back off. This history \a maintainad In taw 
8*bit Mgteryriifiui one aadt for deferences and for back offs. At aad\ altan^t to send a 
packet these bytes era Shifted left one bit. The lowest bit of aa^ byte is then set if the 
node had to defer or back off, respectively, on that alten^t, else this bit is cleared. In 
effect the history bytes remember the deferenoe and back off hirtcry for the lest eight 
attempts. 
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(d) Node Address Assl c rment Dlalog yg 

t — Inier-Frame Gap ( < 200 mlcrosecs ) 

T " inter-Dlalogue Gap ( > aoo microsecs ) 
~ randomly generated time interval 

5 fiBLAP Timing Uagrams 
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The history byte is- used to edjust %. gktaJ bmekeff imsk The mesk takes values in the 
range $00 to SCff*. lAwn the first attempt is made to send a particular fkwra» and the node 
mist defer, the imsk is 0R*ed with $01, thus setting its kwest bit. 

The number of set bits in each history byte provides a count of the number of times the 
node had to defer (back off) in the last eight attempts. Ihis is used to adjust the mask 
as follows: 

* If the number of times the node backed during the last 8 attempts is greater 
than 2. the mask is extended by one bH (up to the maximum of 4 bits) and the back off 
history byte is then cleared. 

* Else, if the number of times the node had to defer is less than 2, the mask is 
reduced by one bH (down to the minimum of IbH). 

* Elsa, if naithar of these apply, the mask is left as is. 

Dkected Transmissions 

Direetad Packets are sent via a 3-ftw dialog as follows: 

LI) The transrr^ter senses the bus until the bus is idle for the n^imum nxi time. 

L2) The transmitter waits an additional time determined by a random number. 

(The actual procedure for generating this random value is discussed below). 

L3) The transmitter sends a UpRTS frame to the intended Destination node. 

L4) The receiver sends a lapCTS frame to the transn^ter. 

L5) The transndtter, upon successful reception of the UpCTS, sends a Data frame 
(in v4\ich it encepulates the client's packet). 

Note: an response frames must be sent within the maximum IFG time. 

The extra wait during L2 tends to spread out transmitters which are contending for the 
line and, thus, minimize (or avoid) collisians. A transmhter assumes that a collision has 
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occurrad when H dots net raoeive a CTS franc in tha rtquirad tima (IFC). Whan this 
happens, the transmitter retries starting at LI. For each attempt, a new random number 
must be generated in step L2. If after 32 attanpts the transmitter is unable to send the 
data fhame, it reports failure to its client. 


Broadcast packets are distinguished by their Destination address being $FF. Vfhen the 
ABLAP TransmItPacket procedure detects this, h performs the following procedure: 

Bl) The transmitter senses the bus untQ the bus is idle for the mmimim IDG time. 

B2) The transmitter waits an additional time detarminad by a random number. 

(The actual procedure for generating this random value is discussed below). 

. B3) The traru^tter sends a lapRTS frame with destination address SFT. 

B4) The transmitter senses the line for the maximum IFG time. 

B5) After sensing the line idle for IFC, it sends its DATA firame. 

The purpose of the BTS in step B3 is to ensure that other transmitters are cognizant of 
the intent to transmit, and to force a ooUision if another transmitter starts at the same 
time. If the transmitter detects bus activity during B4, it makes up to 32 further 
attempts beginning wHh step Bl. If H fails to transmit the data frame after 32 attenpts, 
it reports failure to its client. 

Broadcast packets are sent without ooUision ezoept in the unlikely eese of another 
transmitter attempting a broadcast at the same time. 
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IEL4. f^Mne Reogptkn 


n-um rtoeptian is in rnsny v«ys the inverse of the frsns trensmission process. 


ABLAP recognizes the bounderies of an incoming tnrrt bgr monitoring the Receive 
Gherecter Available boolean variable provided bgr the Fharsieal Layer. Bach incoming octet 
is passed to the Receive Itame (Vmetion untQ an Ettd of Draine boolean variable is set ^ 
the Ihysieal Layer. The received frame can generate several conditions that must be 
handled by ABLAP: overrun Bror» bod frame Size* undemm bror. bed frame Type, and 
bad frame CRC. 

^rame_^^e_^^or 

If a frame (excluding the PCS), of greater than 603 bytes or smaller than 3 bytes is 
received then H is rejected and a badframe error status generated. 


OverrunAJhderrun ftrer 

If ABLAP was not able to stay synchronized with the incorrung data, causing receiver 
ovazTuns or underruns, the frame will be rejected and an overrun or underrun czror 
generated. 

ITame Type 

The frame’s LAP type field is themed agunst each of the valid values for a ABLAP frame. 
Otherwise the frame is rejected and a bad frame tyi^ error is generated. 

Pbame Cheek Seauenoe 


The CRC-OCnr frame ^teek sequence is computed for the mcorrang frame. Vhen the 
entire frame has bean received, ABLAP tests the computed PCS for the frame. The CRCok 
Boolean variable is tested to determine whether the frame wes received without 
transmissian errors. If the CRC is in err o r the frame is rejected and a badframe CRC 
error is generated. 
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If the destinalion address of the frame is not equal to that of the receiving node or a 
broadcast frame, then the rest of the frame is ignored. 
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IVX mohal OBMUnts. T rr^* 


Thit folk<wing oonct's, t)^'s and var« are used throughout the model. 


const 

mlnFrameSlze - 3; 
ma)^rameSl2e - 60S; 
ma^oatasize - 600; ( 
DllTlme - A.3ft; 
OyteTlme • 39.0; { 

mlnIDGtime • AOO.O; 
lOGslottlme - 100.0; 
maxlFGUme - 200.0; 
ma)Oefer$ • 32; ( 

ma) 0 Dollsns • 32; 
lapENQ - sei; 
lapACK • S82; 
lapRTS • S84; 
lapCTS - ttS; 
MICFLAG - S7E; 


I smallest (LAP header only) frame ) 

{ size of largest L/^ frame IncluOlno FCS ) 
size of largest (encapsulated) ^BLfiP data field ) 

( Dlt time Oisw) ) 

worst case single Dyte time (psec) ) 
minimum inter-Olalog Gap In (isec) ) 
slot time of transmit Dacmjff algorithm (psec) ) 
ma^dmum Inter-Frame <^Gap In (psec) ) 

* defers for a single pacKet ) 

* collisions for a single packet ) 

LAP type field value of ENQulry frame | 

• " • ACKnowledgement frame ) 

“ • RequestToSend frame ) 

■ • • ClearToSeno frame ) 

( value of an HXC flag ) 


{ giooal result types from lap functions ) 

TransmltStatus • ( transmltOK, excessOefers, excessOollsns< dLpAOdress ); 
RecelveStatus • ( recelveOK, Receiving, nuiiRecelve^ frameError )i 
FrameStatus - ( noFrame, la^ATAframe, 

lapENQframe^ lapACKframe, lapRTSframe, lapCTSframe^ 
badframeCRC^ oa o f ram e size, baoframeType, 
ovemjhError.. uifipmrtFnor j; 


{ Data Link types and structures ) 
bit - 0-1; 

bltvector - packed array [0-7] of bit; 
wtet • Soa.SFF; 
anAOdress - octet* 
iLAPtype - octet; 

aDataFleld - pad^ array [l.jna;OataSlze] of octet 


{ basic structure of an ablap frame« not Including FLAGs^ FCS ) 
fr ameln ter pretat lo n ■ ( ry v, structured ); 
aFrame • packed laooid 

case framelnterpretatlon of 
raw: 

rawOata : packed array [l-ma;^rameSlze] of octet 
suuctured: ( 
ostAddr : anAdoress; 
srcAdor : anAddress; 
lapType : aLAPtype; 
dataFieid : aDataFleld ) 
anct 
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MyAiJdress ; octet; 

Backoff : kiteger; 
fAdrvatht 
fAdrlnuse^ 

fCTSej^jected : Ciooleaa* 
defeiCountr collsnOo^t : iMeger; 
defeiHlstoiy^ collsnHlstory : Ditysctor; 
outgoingLen^ IncomlngLength : imagBr: 
out^lngPackeC IncomlngPacket : aFrame; 


set during InltlallzeLAP } 
current Backoff range ) 

MyAddrees nas Been vaildldated ) 
another node has same f^Address} 
RTS res oeen sene CTS Is valid ) 
optional for statistics only ) 


lV.i^ Ihtarfaee IleciiretfaM 

The foUowlntf dtdareikns refer to herdwe specific inierfeoes %rfhich ere essuned to be 

a 

•veileble to the LAP procedures. The functions ere tTpiceUy bHs end cr bytes oonUined 
in the relevent herdvare interfeoe chip<s). SimOerly, the procedures ere expected to be 
represented bt eettiel herdvare by meens of control bits within the hardvare. 

Vie %riU briefly describe the assumed attributes of ead\ of these. Appendix 1 defines the 
correspondeiMS between these definitions and the actual interfeoe relevant to the 
hardware of the Lisa and/or Kae (%d\i^ Implements AppleBus via the ZQo^ Sniel 
Cofmunicetions Controller CSCC». 

CanteiSense indicates that the hardwere is sensing a fbame on the bus. 

RcsOat^vall indicates that a data byte is available. 

nOATA is the next data byte availal^ (as indicated by BcvDataAvail). 

EndPfFrame irtdicetes that a valid closing FLAG has been detected. 

CROCK indicates that the received frame's PCS is correct (vAten findOfArame is 
tnae). 

OveiRm indicates that the code did not keep up with data reception. 

MtsslnodocK indicates that a missing clock has been detected. 

WtAddreat sets the hardwere to receive frames directed to HyAddress. 
erat>ieT)QrtVEgS and rtieaMsTi Ortvers oontrol tha oparation of the RSH22 drivers. 
an^fleTx end db^iieTx control the operation of the data transmlttar. 
bfLAG causes the transmission of a JLAO. 
taOATA causes the transmission of a data byte; this is WR8. 

CfCS causes the transmission of the frame Cheek Sequence. 
bdOhEt causes IZ* ones (I's). 
iBsgtPx. enahteRx and disabiaRx control the receiver. 
lesetHtoinaCloOk rmees the MissingOoek indication to ba daarad. 

{ hardware Interface ftnctlon$4)rocadure$ } 

flycUen CarrierSense : booleah; extemai; 

fVrctlan R)08taAvall : booleaa* extend 

flicUan nOATA : octet; extemau 
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function EndOfFrame : tiooleaa* 
ftivtlan CRCok : txnlOen; extemal; 
flnctlon OverRin : txxdeaa' 
function MisslngClock : txxdean; 
procedure setAddressC addr : octet ); 
procedure enaoieljOrlvers; 
procedure dlsab)eT)£)rlver$: 
procedure enacieTx; extemed; 
(xooedure u^laG; 
p ro c ed u re data : octet ); 

procedure U^CS; 
procedure txorsEs; 
procedure dlsabieTx; 
procedure resetRx; 
procedure enanieRx; 
p ro ced ure dlsanieRx; 
procedure resetMissingClock; 


extemal; 

external* 

exteiTBl; 

external 

extemal 

external 

extemal 

extemal 

external 

external 

external 

external 

extemal 

external 

external 
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IVJ3. ftitertaoe Procedures and FUncttais 


The ABLAP model's inierfsce to the mxt higher Uyv (its client) is specified in terms of 
the folkwing three cells: 

Procedure WtiailzeL^ tilnt : octet: server : taoiaen ) 

This procedure inHulizes the ABLAP; H is expected to be celled exactly cnce. The 
Mnt parameter is a suggested starting value for the node's ^pkBus physical lirUc 
address; a value of 0 irxiicates that ABLAP generate a starting value. Upon return 
from the call, the station’s actual address is available in the globel variable 
HyAddress. if ser ves is true then the internal procedure acquilcAddnsss will spend 
extra time to determine if another node is using the selected node address. 

FuxUon transmltPactcetf dstParam ; anAnaneg; troeParam ; aLAPtroe: 
dataFielO ; aDataFteiO; dataLenoth ; intodar i : Thansmitstatue;: 

This is the call provided to transnut a paeltet across. Ihe intenMl function 
TranBTritLInXMgrnt : lYansmItStatus performs the tiansmission Link Access 
algorHhms. 

Function iBceluBPackstf var dstParam : an^Mress; var srcParam ; snAddress: 
var tvoeParam : aL^voe: var detsFielo : sDataFleld: var delaLanotn : Inteder I 

T^is is the «\try provided to receive a packet. The intemal function 
ReceiveLk\kMgrrt : R-ameSletus; implements the reception Link Access algorithms. 
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mitiAiiym ps> 


hitkIhwLAP is eaSlsd to rssst ths global variablss to Icnown states; it calls 
aoquireAddress to Initialize KyAddress. 

prooedure InlUailzeL/*^ nint : octet; server : ttmeen ); 

w 1 : Intagar; 

oegin 

Backoff 0; 

( imualize history data for Backoff calculations } 
nr 1 0 to 7 QD 
08^ 

oefeiHlstor^l 0; 
oollsnHistoi]^] f 0 


aefeiCQU^t 0; oousrcoim O; foptlonai) 
acquireAdoressC hint, server ) 


IVLB. AOttijeAdqress ftoeetoe 

The preeedure acaflreAfldrBSS provides the dynarme node assignment algorithm, K 
special tevm (of type is craated and sent. When no node responds after 

repeated attennpts, the current value of HyAddresi is assumed to he safe for use bgr this 
node; the state of fAiih^Sd reflects this fact. (If the global f AdrlnUse ever becomes 
true after a eaU to aoquireAddress, another node that is using the same HvAddress has 
been detected.) 

procedUEre acquire^^ldress( tdnl : octet; server : tsoolesi ^ 
var maxTrj^, trys : integer; ENQfreme : aFrame; 
beg^ 

if hint >0 
t!«n 

My Address r* Wnt 

dee 

If server 
men 

MyAddress r» Random( 127 ) * 128 

ttat 

MyAddress RandcrnC 127 )• 1; 
set^ldressC MyAddress ); 
fAdtvaUd .- false; 

If server 
then 

maxTrys :« 1500 
dee 

maxTrys ?• 50; 

( the mein ioop of acqulre^iaress; repeatedly check for response to ENQ ) 
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npeat 

irys 0; f AflrlnUse false; 

%^e trys < ma^n^rys do 

if (uansmltPacket( My^ress, lapENQ. EisQfranie^taFleid, 0 ) 
• transmltOK) or fAorinuse 

tren 
aegin 
If server 
then 

MyAOdress Randar< 127 )« 128 

ttse 

MyAddress Randorr< 127 )♦ 1; 
setAddres$( MyAddress ); 
trys 0 
and 


If trys < maxTrys 
then 

trys trys • 1; 
else 

f Adrvaild true 
tfiUl fAdrvaild 


IVjS. TtensmitPacket 


The function trargfTtftPacicet is celled by the ABLAP dient to aend « packet. After 
oonstntcting (encapsulating) the caller's dataParam, H calls upon TtansmitLinkMgrnt to 
perform the actual link access. 


ftfictlcn trarttmltPackeU 
dstParam : anAddress; 
typeParam : aLAPtype; 
dataParam : aDataPleia* 
datauength : Integer ) : TransmltStatus; 
be0n 

If f^lnuse 
than 

transrrdtPacket dipAddress 

else 

{ copy Interface data Into frame for Transmlu.lnkMgmt ) 
with outgoingpKt do 
begin 

dstAddr dstParam; 
srcAddr > MyAddress; 
lapType typeParam; 
dataFieid > dataParam 
«kl‘ 
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outgoln^engtf) :• dataLengtn « 3; 
transmitPacket :• TraremltLlnkM^t 

IV.r. TMmlUJrtcMamtFUftctfan 

The function TransmttU «*^^qpft iirpkments the Carrier Sense, Multiple Access w/ 
CoUision Avoidanae algcrithin; TrannnitLinkMgnt is «t the heart of the AppleBus Link 
Access PtotocoL 

The tonP*cal ^pkBus hard^^ere is no4 capable at performing ooUisian detection. 

LAP attempts to rrmin^ odlisions by requiring transrrdtters to wait a randomly 
generated amount of before s end i ng their RTS frames after the bus has been sensed idle 
for a minimum time (the IDG). Any transmitter which detects that another transmission is 
in progress vSiUe it is in this random wait must defer. 

In crdnr to ndnimize delays under light loading, but stDl ba able to miniiniae the 
probeb&Hy ot ooUisions under modarata to heavy loading, the random delay is picked in a 
range that is oonstently adjusted based upon the recently observed history of a node's 
attempts to access the bus. Two history vectors CdefglHIstOfV and COUgHlstOTV) are 
used to keep treck of the last 8 aooess attempts at the bus. Each eitempt adds a single 
bh of history data to these vectors by shifting left the current values and updating the 
VMited bK with the appropriate velue. defcrHistory(0] is set if a daftranot is raquirad 
during an access; ooUsnHistoiy [0] is set if an attempts result in an assumed collision 
(La. back ofO- 

The range of the current Backoff is ad>astad up%«rds (to a maximum of 18) whan the 
observed oolllskns exceeds Z in the last 8 attempts; Backoff is adjusted downwards if 
the rmttoar of observed defermoes is less than 2 in the lest 8 attempts. Vihen an 
adjustment is made, the oorresponding history data is set to the "maximum" valw so that 
further adjustments are inhibited untQ more history data has aecumulatad. The maximum 
value for dcferHistory is dl I's; the maximum value for ooBsnHistoiy is all O's. 

Note that a kcal backoff (LdBackOff) is used during Ute retry atten^ts of a given frame. 
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This has the effect of spreading out attemfpts to a non-liatening node for a longer time, 
thus increasing its chano^ of receiving our packet. 


ftficUan TransmitLinkMgmt : TransmitStatus; 

war 

LciBackOff, 1 : imeger; 
fBroadcast,, fENQ : Dooleaa* 

MhUimer : real; 
rcvdframe : FrameSlatus; 

RTSframe : aFrame; 
begin 

with RTSframe do 
begin 

dsiAddr outgolngRacketostAdor; 
srcAOOr MyAooress; 
lapType lapRTS 
enct 

fBroaocast outgolngpacket-OstAdOr - IFF; 
fENQ outgolngPackeLiapType - lapETNQ; 

{ adjust Backoff, based ipon reoent history ) 
tf bitCotnU OollsnHistory ) > 2 
than 
begin 

Backoff mln( ma>< Backoff • 2, 2 )i 16 k 
for 1 0 to 7 do 
coilsnHlstor>(l] 0 
and 
else 

If bltCoJit( oeferHlstory ) < 2 
then 
begin 

Backoff Backoff div 2; 
for 1 0 to 7 do 

<JeferHlstor>p] i 


( shift history data ) 
for i :• 7 dovmto i do 
be^ 

oollsnHistor){l] oollsnHistonO”!^ 
defeiHistory(i) :• oefeiHistor/l-l) 
and; 

collsnHlstoryfO] 0; deferHlstor)(0] ;• Q; 

{ initialize main loop ) 

defcrTries O; oollsnTrtes 0; 

LciBackOff BackOff; transmitoone > falsa; 

(begin main loop of TransmitLinkMgmt) 
repeat 
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{ Walt for minimum InteiOialogGap time ) 
repeat 

{ wait for any packet In progress to pass ) 
tf CarflerSense 
then 

( ertture minimum backoff If packet in progress ) 

LclBackoff ma}< LclBackoff« 2 )i 
oeferHistor>(o] i; 

( perform watchdog reset of Rx for "stuck* carrlersense ) 
xmtUm er RealTlme * msDf rameSlze * oyteUme; 

undl not CanlerSense or (RealTlme > wittlmer); 
if Carrlersense 

then (somev^*$ wrong, clear It} 

resetRx 
arat 

{ wait for minimum lOG after packet (or Idle line) } 

»T>tUmer :• F^Tlme <» mlnlOGtime; 
repeat 

witU (RealTlme > renttlmer) or CarrieiSense; 
ifiUl not Carrlersense; 

( Walt our additional backoff time, deferring to others } 

agnttiro r :• RealTlme « RandomC LclBackoff ) • IDGslottlma!; 

repeat 

tfiUl (V^Tlme > )gnttimer ) or CarrlerSaise; 

then fdefer} 

lncr( OeferCount }; fcptlonai} 

LclBackoff :• ma)< LclBackoff, 2 ^ 
deferHlstoT>(0] 1; 

If defer Tries < ma^Oefers 
then 

deferTrles deferTrles « 1 
eUe 
begin 

TransmltLlnkMgmt exoessOefers; 
transmltdone :• true 
wm 
(M 

eiie fnot (Carrlersense or MlsslngClock]} 
be^ (send our rts/enq and await cts/ack) 

tf fENQ 
then 

transm!tFrame( outgolngPackeL 3 ) 

aiae 

transmltFrame( RTSframe, 3 ); 
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( use c onmon code to detect line state ) 
fCTSejqjected true; 
rcvdframe recelveFrame; 
fCTSooected :» fUse; 

If fBroadcast and (rcvdframe - noFrame) 
men 
begin 

transmllFrameC outgoln^>aciceU outgolngLengtn ); 
TransmliLlnkNtgmi transmltOK; 
transmlusone true 


If rcvdframe - lapCTSframe 
tnen 
be^ 

transmllFrameC outgoin^acket, outgolngt.engtn ); 
TransmltLlnkMjmt transmltOK 
transmltdone true 


{ assivne collision If we don't receive the ej^ted CTS ) 

If not transmltdone 

then . {CTS not seert Initiate retry} 

begin 

inci( CollsrCoint X* {optional} 

' ooilsnHl$tor)(0] 1; fipdate history data} 

If collsnTrles < makOollsns 
then 

collsnTrles collsnTrles ♦ 1 
else 
begin 

TransmltLlnkMgmi excessCollsns; 
transmltdone true 
end 
ertf 


and ^ise« not CarrlerSense) 

iftUl transmltdone 
end; 


IVjB. TtansrrttFrame Prooadge 

The ^I'ooedure traramltFrame is responsible for putting deU on to the bus. Notice thet 
oerUin detells, such es how e FLAG is forced and a packet terminated (vfhieh includes 
sendir^ of the FCS) are not explicitly detailed here due to their extreme hardware 
dependence. Note: the 12 ones at the end of the frame are required to fini^ docking of 
data by a receiver. 
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proced u re transmitFrame( var frame : aFrame; frameslze : Integer ); 


¥V 

1 : IrHeger; 

DUUmer : real; 
begin 

msaDieRx’ 

{ generate tne Synchronizing Pulse ) 
bltUmer RealTlme * 15 • oltTlme; 
enabieT)Orlvers; 
v^hlie RealTlme < bltUmer db 
begbt end; 
dlsabieT)Orlvers; 

bltUmer RealTlme ♦LS * bllTime; 
v^tUe RealTlme < bltUmer do 
betfnend; 

( start the actual frame transmission ] 
enabieT}Orlvers; 
enableTx; 

for 1 1 to frameslze do 
T)Oata( framejawDataO] ); 

U^CS; 

txOKES; 

dl$abieT)Orlvers; 

( re-establish default listening mode ) 
resetMlsslngciock; 
enabieRx 
end; 


{ output 2 opening flag's } 


{ send the FramecneckSequence ) 
I the trailing flag ) 

{ send 12 ones for extra clocks ) 


1V5. ReoelvePacket PtwediK 


The procedure reoelvePacket is the primery interfeoe routine to higher levels. It is 
specified ea if H is aynehronously celled by the user. Noie that in many in^leirentetians, 
the kemr-levei Beoetv^inkMgmt function vnuld be Invoked by en Int^rupt routine. 


prooediie recelvePackeU 
ver dstParam : anAddress; 
var srcParam : viAddress; 
var typeParam : aLPRtype; 
var dataParam : aoatafleid; 
w dataLength : integer ); 
var status : RecelveStatus; 
bB 0n 
lepeek 
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status RecelveLlnkMgn>t; 

If status • reoelypOK 
tfien 
begin 

lylth lncxmln^>acket do 
begin 

OstParam :• dstAOdr; 
srcParam srcAoar; 
typeParam lapType; 
oaiaParam oataField 
end; 

oataLengtn f IncomlngLengtn 
and 

(fiUi status • recelveOK 

wt 



The function ReoelyeLlrtcMjnt implements the reoelvur side of the Link Access Protocol; 
h would typicelly be celled from en interrupt routine rather than reoaivePeckei. 


ftsctian ReceiveLlnkMgmt : ReoeiveStatus; 

status : ReceiveStatus; 

CTSframe, ACKframe : aFrame; 
begin 

status :• Receiving; 
a^dle stetus « Receiving do 
case receiveFrame of 

badframeCRC, badframeSize, bedframeType, 
undemsCnor, ovemjnError: 
status :■ frameEiror; 
lapENlQframe: 
if fAdiVBlid 
then 
be^ 

ACKframe.dslAddr :• incomin^ackeLsrcAddr; 
ACKframe.sicAddr :■ My^Sdress; 
ACKframe.lapType :■ lapACK; 
transmitFieme( ACKframe^ ); 
status :• nullReceive 
end 
else 
begin 

f AdrlnUse tn«; 
status :> nullReceive 

lapRTSframe: 
if fAdrvalid 
then 
begin 
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CTSfram&dstAddr incomingPacket.srD^)dr; 
CTSfrapresrcAOdr h^Adctress; 
CTSframe.lapType la^TS; 
jtransmltFrame( CTSframe^ 3 ) 

end 

ttie 

begin 

f Adrlnuse tiue; 

status :• nuilRecelve 
end* 

lapOATAframe; 

If fAdrvaiid 
tnen 

status iBcelveOK 

aise 

begin 

f Adrinuse tiue; 
status :• nullRecelue 

n o F rame : 

status :• nuURecelve 
end {case recelvePrame); 

RecelveLlnkMgmt :• status 
end 


iV-11- PanelveFrame fUnctien 


The function leoeiveFrame is responsible for interacting with the hardware. 


flnctJan leceiveFrame : FrameStatus; 

ver rcvUmer : real; 

begin 

{ provide timeout for Idle line | 

rcvtim er RealTIme « maxlFOtlme; 
npost 

tfvtU carrlerSense or (RealTIme > rcvtimer); 
If not CarrlerSense 


be^ 

recelveFrame noFrame; 
eidt( recelveFrame ) 
end 

{ line Is not ldle« check If frame Is for us ) 
rcvtlrn er RealTIme ♦ maxlFQtlme; 

fBpBSt 

tntU RxcnarAvail or (RealTIme > rcvtimer); 

If RxcnarAvall 
then 
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tngin ( receive frame ) 

error false; framedone false; InoomlngLengtn :• 0; 
ispost 

fcvtirre r RealTlme ♦ 1.5 • DyteUme; 
ispsst 

tfitU RxCnarAvail or (RealTlme > rcvUmer]i; 

If RsdCriarAvaii 


Degln 

tf ^/erRif) 
then 
tiegiln 

receiveFrame :• ovemrError; 
error true 

ml 

else 

If IncomlngLengtn < ma^^rameSlze 
ttcn 
begin 

IncomlngLengtn :• IncomlngLengtn <» i; 
lncomlngPacket.rawOata(lncomlng(Langtn] nOATA 
end 
else 
begin 

receiveFrame :• badframeSlze; 
error true 

If EndOfFrame 


begin 
If CROOK 
then 
begin 

IncomlngLengtn :• IncomlngLengtn - 2 : (accoint for CRC) 
If IncomlngLengtn < mlnFrameSlze 
then 
begin 

receiveFrame bad f rameSlze; 
enor true 


framedone :• true 
and 

else (bad CRC) 
be^ 

receiveFrame badframeCRC; 

error :• true 

end 

and {If EndOfFrame) 
end {If RxcnarAvali) 
else { RealTlme > rcvtlmer ) 
be^ 

receiveFrame uxJerrvnError; 
error :• twe 
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end 

(fiUl fr a medone or error; 

( check on validity of the frame ) 

If framedone 
then 

If f Adivaiid 
then 

{ if our address is valid, check on actual type | 

If IncomingpacketlapType < S80 
than 

receiveFrame .*• lapOATAframe; 

elia 

case incomingpackeUapTyp^ of 
lapENQ; 

receiveFrame lapENQframe; 
lapRTS: 

receiveFrame lapRTSframe; 
lapCTS; 
if fCTSOk 
then 

receiveFrame :• lapCTSframe 

elie 

DBQpi 

f Adrlnuse :• true; 
receiveFrame oadframeType 
end; 
otherwise 

receiveFrame .*• OadframeType 
end {case incomingPacketiapTy^) 

else 

( we received something which we didn't aspect ) 
Oegin 

f ^IrUse :• tiud; 
receiveFrame :• noFrame 
end 


end (if RjcCharAvail) 

else ( no R)OtarAv^l ) 
receiveFrame noFrame; 

resetRsv lesetKssingClock 
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yv i», ftwidUTM «ar>d yiir>etien> 


ThB foUowinit law-ltvttl routinM ar> rtftrtnoad by tht atav code. 


pTDcedLire inci< var i : integer ); 
begin 

i i ♦ 1 
, and; 

Afction bltComU bits : bitVector ); 

wv sum ; Integer; 

beg^ 

sum :■ 0; 
fbr i :• 0 to 7 do 
sun :« sun ♦ bits(i]; 
bitCcKjnt sun 

fuction min( vail, val2 : integer ) : integer; 
begin 

if vail < vai2 
then 

min .*« vail 
blae 

ndn :> val2 

ftfction ma)< vail, val2 : integer ) : integer; 
be0n 

if vail > val2 
then 

max :« vail 
dse 

max :■ val2 
•at* 

fUrction Random( maxval : integer ) : integer; 
begin 

( note; this is implemented as any "good" random nunber generator 
%mich produces a result in the range CLmaxval*!. ) 




Ap«— 1. 9CC IinplefnBnt«tian 

This appendix axpluns how the harduar* intarfaoa routines de^ared in section IV.3 are 
actually implemented on the Mac, which uses the ZOott** SCC as its primary interface for 
AppleBus. Note that all of the register and bit names below are those used by ZHof’ in 
hs see documentation. 

CarrierSente indicates that the hardware is sensing a fhame on the bus; this 
oorresponds to the oomplemant of the 3YNC/HUKT bit in RRO. 

RctOataAvall indicates that a data byte is available; this oorresponds to the Rx 
Av^n^KU bit in RRO. 

DOATA is the next byte from the bus; H is RR8. 

EndOfFrame indicates that a valid closing ILAG has been detected: this is the End of 
Frame bit in RRi. 

CftOok indicates that the received frame's FC8 was o cei act (when EndOfirame is 
true>; the is the cewolemaBt of the CRC/Frandrtf Error bit in RRI. 

^agPin mdieates that the oode did not keep up vdth data reception; this is the Rx 
Ovarrun bror bit in RRI. 

MbslnoClOCiC indicates that the herdware has detected a missing transition on the bus; 
this is the One Qeek Missintf bH in RRIO. 

tetAddress is a procedure vd\i^ sets the hardwire to receive packets vhooe 
destination address matches MyAddress; this simply sets WR$ in the SCO. 

WiBtoleT)d3riuers and CteahteTiOrivers oantrd the operation of the RS-422 drivers. On 
the Mac, this is controlled by the RTS bit in VRS. 

enableTx and dtsabieTx control the operation of the trensmitt«r; this is done by means 
of the Tv KnaHU bit in WRS. 

tafLAG esusee the trensrrusskn of a ILAO. Ihis happens autormtieally at fTama 
^paving vA«n Tx Enable is set; howavor, the oode imst delay long enough to cause the 
axtra FLAO. Ihe trailing FLAG is generated automatically at frame end as part of the Tx 
Ghdarrun proeessing. 

t)OATA causes the transmission of a data byte; this is WRS. 

tlfCS causes the transmission of the fyame Check Sequervoe. This is caused 
automatically by letting the Tx Underrun occur. 

txQhCs causes 12-*- ones (I's). This is done by disabling the SCO transmitter (setting 
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Tx biihk to 0)t v>h!]* Inving the 422 drivers on (RTS set to IX vtd delaying. 

lesetRx, enebleRx and cflsableRx oontrol the receiver; this is done by means at the Rx 
Enable bit in V>>R3 . lesetRx should also flush of the receive FIFO. 

lesetMisslnoClOCk causes the MissingQock indication to be cleared; this is done by a 
Reset Missinfl dock command via WR14 . 
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1. INTRODUCTION 


This is a general document covering the overall architecture and other global protocol 
issues for AppleBus. Simple but effective protocols are defined at the network, 
transport and session levels. Protocols for the presentation and higher levels will be 
discussed in another document. 

LI Basie Goals: 

In setting a clear goal for the architecture we must keep the following in mind : 

(1) Open Systems Architecture ; 

We must not build a system that is a "strait jacket* that restricts developers of 
AppleBus systems from expressing their creativity. Nor should we restrict their ability 
to add to the architecture specific functions and features for their particular 
applicatims. With this in mind. AppleBus has a simple, layered architecture that allows 
protocols to be added at any level, and that specifies a small repertoire of protocols and 
access methods for only the lowest layers (network, transport and session). No attempt 
is made to mandate the use of these protocols; they are simply reotmmended by Apple for 
effici&ncy and compatibility. 

(2) Simplicity and Versatility; 

Compared to the many currently available local-area interconnect systems with speeds 
in the megabit-per>sec(md plus range, AppleBus is a modest speed interconnect system. 
This leads to some important conclusions relevant to protocol design: 

• to keep the station latency low, the number of nodes on an AppleBus will in most 
cases be modest (cm the order of twenty-five nodes), 

- it is important to keep packet headers as short as practical withmit loss of 

functionality, 

- interconnection of AppleBuses amar^ themselves and with other networks is an 

important part of the protocol design. 

The architecture must be versatile enough to satisfy the needs of both a pwlpheral 
bus and a network interconnect system. 
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The protocols and access methods proposed here should be viewed as versatile 
primitives with which developers can incorporate AppleBus into an interconnected 
system of personal cmnputers, peripherals, servers, and communication to other 
networks and mainframe resources. 

(3) Support Third Party Developm«it : 

Apple is not proposing to build the entire network system by itself, or as a cmnplete 
closed system. Apple wants to provide the correct framework to facilitate development 
by others and will provide the key building blocks and certain exemplary services (e.g. 
file servers) that can serve as the basic foundatim for other services (e.g. mail, print 
spooling, etc.). 

The architecture is discussed here using the terminology of the widely referenced ISO 
Open Systems interconnection framework. 

While layered architectures might to some appear complex, layering can in fact reduce 
complexity and enhance maintainability by partitioning the system into small, manageable 
chunks, each performing a well>defined function. But complexity and inefficiency can 
result from the implementation of each layer as a separate module with interfaces based 
on high overhead operating-system calls. It is important to realize that architecture 
diagrams should not be used as models for modular software implementati<m; they are 
pictorial representaticms of the logical interrelationship of the diverse protocol functions 
and services offered by the architecture. 

Layered architectures do not imply "buffer-copying* to move data from layer to layer. 
The implementer can design the various interfaces to avoid copying. 

1.2 Overall Reouiremmts and a Global Structure: 

The AppleBus Link Access Protocol (ABLAP) provides the basic tmderlying service of 
packet transmission between the nodes of an AppleBus. The main goals of the datalink 
protocol for a shared bus system like AppleBus are as follows : 

1. provide access control; 

2. provide a node addressing mechanism; 

3. ensure packet integrity. 
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The ABLAP uses s CSMA/CA (CSsrr/er Sense Multiple Access with CoUiBion Avt^dance) 
protocol for access control. Node addressing is done in the LAP header using one>byte 
source and destination node IDs. Packet integrity is ensured through the use of a 
two-byte checksum (CRC-16) at the end of a LAP frame. 

The LAP'S service roust be augmented by the higher layers of the architecture with 
certain additional features : 

(1) Sockets : Nodes on the system should be allowed to aptablish /create 
network-addressable logical entities known as sockets . 

(2) Socket-to-Socket Transport : The basic transport fiinctimis of the system will 
provide a best-«ffort datagram transport service between any pair of sockets on the 
system. 

(3) Reliable Transactions ; The basic aocket-to-socket transport of datagrams is 
inadequate in many respects. In particular, its level of reliability (loss of packets, 
out-of-sequence and duplicate delivery of packets, etc.) is c^tm inadequate. A very 
useful added- value transport service allows the client of a socket to send a transactim 
request packet to the client of another aocket and to receive a transactim response with 
high reliability, in the face of the usual problems of packet loss, etc. 

(4) Reliable Data Streams : Another class of socket clients will be exchanging sequences 
of data (e.g. screen contents, keyboard input, etc.) that they perceive as an arbitrary 
stream of bytes. Such clients need a reliable data stream service that takes care of 
problems such as data packetization, lost pacicets. out-of-sequence packets, and 
duplicates. 

(5) Name Binding : The basic network-visible entities are the clients of sockets. These 
can be identified by their socket identification numbers (plus the node ID). This use of 
numbers is very efficient and appropriate for the network protocols but extremely 
inconvenient fcMr the users of the network system. The latter would much rather refer to 
objects by their names (strings of characters). To make this possible we need a aervice 
that translates user-provided names into network addresses /identiHers such as socket 
identifiers, node numbers, etc. 
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(6) Special Function Protocols : This group includes protocols for controlling devices, nie 
server access, etc. These are usually tailor-made for the specific service /function and will 
not be discussed here. 

The AppleBus protocol architecture illustrated in figure Arch 1 was developed with these 
considerations in mind. This document covers the protocols indicated by gray shaded boxes 
referred to as the core of the AppleBus protocol architecture. 

Although several of these core protocols have been implemented and tested, others are. as 
of this date, in a state of further reHnement and development. In particular, the Data Stream 
and Zone Informaticm protocols should be treated as proposals potentially subject to 
significant change. 
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Abbreviations 

ABLAP — Apple Bus Link Access Protocol DSP — Dete Stream Protocol 
ATP AppleBus Transaction Protocol OSAP — Data Stream Access Protocol 

DCP -- Device Control Protocol FSP — File Server Protocol 

ODP — Datagram Delivery Protocol hBP — Name Binding Protocol 

" 'MP — Routing Table Maintenance Protocol ZIP — Zone Information Protocol 

naure ArchJ : AppleBus Protocol Architecture 
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II. DATAGRAM DELrVERY PROTOCOL 


II. 1 Terminology 

As noted in the introduction, the AppleBus Link Access Protocol (ABLAP) provides a 
node-to-node delivery of packets, with a best effort performance, on a tingle AppleBus. 
The Datagram Delivery Protocol (DDP) extends this mechanism to socket-to-socket 
delivery. DDP packets are referred to as datagrams. 

DDP has been designed to provide this service over an AppleBus internet (see Figure 
DDPl ). As illustrated there, an AppleBus Internet consists of one or more AppleBus 
systems interconnected by bridges. Bridges are also referred to as Internet routing nodes 
or internet routers. A bridge will often omsist of a single node connected to two 
AppleBuses, or it might consist of two nodes each of which is connected to an AppleBus 
with the two nodes further connected to each other through a communication channel. As 
far as the protocol architecture is cmcern^, the chumel between the two halves of- such 
a bridge could be a leased or a dialup line or, in fact, it could be another network, e.g. a 
wide-area packet-switched or circuit-switched public network, or a higher speed 
broadband or baseband LAN used as a *backbone". 

Bridges are packet forwarding agents. Packets can thus be sent between any two 
nodes of the internet by using a store-and-forward process through a series of internet 
routers. By combining this facility with DDP, packets can be sent between any two 
sockets on the internet. 

Sockets. Socket Numbers : 

Sockets are logical entities in the nodes of the network. Dstsgrsms, packets that are 
delivered as single, independent entities, are exchanged between sockets. Sockets 
should be visualized as the sources and destinations of datagrams. 

Sockets are identified by a socket number. Socket numbers are one byte (8 bits) long. 
Thus there can be at most 256 different socket numbers in a given node. Two of these 
values are reserved "0" to mean an unknown socket, and 255 for future use. The 
theoretical maximum number of sockets in a single node is thus 254. 
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SUtically-AasIgned and Well-Known Sockets 


Sockets are owned by socket cUenta. These are typically processes (or functions in 
processes), ImplementM in software in the node. A socket client can send and receive 
datagrams only through sockets that it owns. 

Sockets are classified into two groups: atatically and dynamlcally-aaaigned. 

Socket numbers decimal 1 through 127 are reserved for use by clients of statically 
assigned sockets (SAS). Examples of such clients are AppleBus core protocols (e.g. 

ATP. NBP. RTMP. etc.) and low-level network built-in services such as echoers. The 
range of socket numbers decimal 1 through 64 is reserved by Apple for use in AppleBus 
core protocols and for future use. Numbers 65 through 127 are available for unrestricted 
experimental use. Use of these experimental SAS is not recommended for commercial 
products since there is no mechanism for eliminating conflicting usage by different 
developers, (see section II.6) Socket numbers decimal 128 through 254 are assigned 
dynamically by OOP upon request from clients in that node. Sockets of this type are said 
to be dynamically assigned (DAS). 

Socket Addresses. Network Numbers and InterNet Addressing; 

No two sockets in the same node can have the same socket number. Thus, the socket 
number taken together with the ABLAP node ID provides an unambiguous identifier for 
any socket a single AppleBus. This is called the socket's AppleBus address. 

This can be extended to a socket address that is unique on an AppleBus internet. 

This is done by assigning a unique network number to each AppleBus in the internet. 

The internet address of a socket consists of the socket number, the node ID (of the node 
in which the socket is located) and the network number (of the network on which the node 
is located). The internet address of a socket uniquely identifies it on the internet. Thus 
the source and destination sockets of a datagram can be fully specified by their internet 
addresses. 

Network numbers are two bytes (16 bits) i<mg. Of these the number 0 (zero) is 
reserved to mean unknown, ie. the local network to which the node is connected. The 
value 65.535 (all bits set to one) is reserved for future use. Packets whose destination 
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network number is zero are addressed to a node on the local network. This allows 
systems cmisisting of a single AppleBus to operate without the need for an explicit 
network number. Although we do not expect our clients to build such a large internet, the 
two byte network ntimber theoretically allows proper operation on an internet with up to 
65.534 AppleBuses. 

DPP Protocol Type Field : 

The AppleBus architecture allows the implementation of a large number (up to 255) of 
parallel protocols at the level above DPP. It is important to realize that socket numbers 
are not associated vdth a particular protocol type and shotild not be used to demultiplex 
among parallel protocols at the transport level. Instead, for this purpose a protocol type 
field is provided in the PPP header. This is one byte wide and is known as the DDP 
protocol type field. 

Socket Listeners: 

Socket clients provide code that is said to be the socket's listener. This is the code 
that "receives” datagrams addressed to that socket. The specific implementation of a 
socket listener is node dependent. For efficiency, the socket listener should be able to 
receive datagrams asynchrtxiously through either an interrupt mechanism or an I/O 
request completion routine. 

The code that implements the PPP in the node must cmtain a data structure called a 
sockets table to maintain an appropriate descriptor of each active socket's listener. 

11.2 DDP Interfsce 

As shown in figure PPP2. the PPP interface is the boundary at which the socket client 
can issue calls to and obtain responses from th e PPP implementation module in the node. 

The PPP Implementatiwi Module supports four calls: 

(i) Open a Statically-Assigned Socket : 

The caller specifies the socket number and the socket listener for that socket. The call 
returns with a result code: 

- success : socket activated 
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- error: 


various cases : socket already active, not a statically- 

assigned socket (outside the range), socket table full. 

(ii) Open a Dynamically Assigned Socket : 

This is similar to the preceding except that the caller does not specify the socket 
number. The call returns a result code and. if this signals success, then the activated 
socket's number. The result code takes the following possible values : 

- success : socket activated 

- error : various cases: socket table full. 

all dynamic sockets busy 

(iii) Close a Socket : " 

This request specifies the number of the socket to be deactivated. If the socket is 
currently active it is removed from the sockets table. The result code has the following 
possible values: 

- success : socket deactivated 

- error : no such socket. 

(iv) Send a Datagram: 

The request specifies number of the source socket, the internet address of the 
destination socket and the DDP protocol type field value. Also the length and location of 
the data part of the datagram are provided in the request. Since DDP includes an opticxial 
software checksum in internet datagrams, the requester must specify whether or not this 
checksum is to be generated. 

The result code has the following possible values : 

- success : datagram sent 

- error : sending socket not active or invalid. 

datagram data too long. 

In addition to these four calls, a socket listener must provide a mechanism for the 
reception of datagrams. 

(V) Datagram Reception by the Socket Listener: 
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We do not specify this function since it is dependent on the implementation in the 
node. Some mechanism is needed to deliver datagrams within the node to the destination 
socket's listener. The DDP package should attempt this only if the destination socket is 
currently active. The DDP must discard datagrams addressed to inactive sockets. 
Furthermore, internet datagrams received with an invalid DDP checksum must be 
discarded. 

11. 3 DDP Internal Aleorithm: 

DDP is a simple, best-effort protocol for delivery of datagrams. As such there is no 
mechanism for recovery from packet loss or error situations. 

Within the DDP implementaticm module, the primary function is to form the DDP header 
on the basis of the destination address, and then to pass the packet on to the appropriate 
LAP. Similarly, for packets received from the LAP, DDP must examine the datagram’s 
destination address in the DDP header and route the datagram accordingly. Details of this 
operation depend on the nature of the node, namely whether it is a bridge or not. These 
are discussed in more detail in section II.S. 

11. 4 DDP Packet Format : 

A datagram consists of the DDP header followed immediately by the data. 

There is a 10-bit datagram length field in the DDP header. (See figures DDP3 and 
DDP4.) The value in this field is the length in bytes of the datagram starting with the 
first byte of the DDP header and including all bytes up to the last byte of the data part of 
the datagram. Upon receiving a dategnun the receiving node's DDP implementatiai must 
reject aJJ datagrams whose irnSicated Imgth is not equal to the actual received Imgth. 

The maximum length of the data component of a datagram is limited to 586 bytes. Longer 
datagrams must be rejected. 

In addition, the DDP header contains the source and destination socket addresses and 
the DDP protocol type. Each of these addresses could be specified as a four byte internet 
address. However, for packets whose source and destination sockets are on the same 
AppleBus, the network number fields are unnecessary; likewise, for such datagrams the 
source and destinaticm node IDs are repeated in the LAP header and are thus redundant in 
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the DDP header. For these considerations. DDF uses^two types of header: a short form 
and an extended form. 

The short form version of a DDP datagram is as shown in figure DDP3. The datagram 
header is five bytes long. The first two bytes of the header contain the datagram length, 
with the more significant byte first. The upper 6 bits of this byte are not significant and 
should be set to zero. The datagram length field is followed by a one byte destination 
socket number, a one byte source socket number, and a one byte DDP protocol type field. 
Such short header datagrams are sent if the source and destination sockets are on the 
same AppleBus. 

The extended form datagram is shown in figure DDP4. The extended form DDP header 
is thirteen bytes long. It contains the full internet addresses of the source and 
destination sockets, as well as the datagram length and DDP type fields. For such 
packets, there is a 6-bit hop count field in the most significant bits of the first byte of 
the DDP header. Datagrams exchanged between sockets on different AppleBuses of an 
internet must use this form of header. In addition, the extended hMder includes a two 
byte .(sixteen bit) DDP checksum field. If the sending client so desires, the source node's 
DDP implementation calculates and inserts a software-generated checksum into this field; 
otherwise, the sending node sets this field to 0. The datagram's destination node 
recomputes this checksiun and rejects the datagram if the received and computed values 
do not agree, (see section II.7) 

The DDP checksum has been provided to allow the detection of errors caused by faulty 
operation (e.g. memory and data bus errors) within bridges on the internet. Implementors 
of DDP should treat it as an optional feature. 

On packets received from the LAP, DDP uses the value of the LAP type field to 
determine if the packet has a short or an extended DDP header. The LAP type field 
values for the two cases are 1 for short form, and 2 for the extended form. 

HCp Counts : 

For datagrams that are exchanged between sockets on t%»o different AppleBuses in an 
internet, a provision is made to limit the maximum number of internet routers the 
datagram can visit. This is done by including, in such internet datagrams, a hop count 
field. 
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The source node of the (tetagrain sets this field to zero before sending the datagram. 
Each internet router increments this field by one. A bridge receiving a daUigram with a 
hop count value of 15 should not forward it to another bridge, but should instead discard 
it. This provision is made to filter out of the internet packets that might be circulating 
in closed routes. Such closed routes (loops) are a transient situation that can occur for 
short periods of time while the routing tables are being updated by the Routing Table 
Maintenance Protocol (RTMP). Nodes other than bridges ignore this field. 

The upper two bits of the hop count currently are not used by DDP, but are reserved 
for future use (such as the extension of the maximum value of the hop count beyond the 
currently allowed value of 15). 

il.S The DDP Routine Algorithm: 

A datagram is conveyed from its source to its destination socket over the internet 
through the bridges. The DDP implementaticxi in the source node examines the destination 
network number of the datagram and determines whether the destination is on the local 
network or not. If it is, then the short form DDP header of Figure DDP3 is adequate and 
the LAP layer is called to send the packet to its destination node. If, however, the 
destination is not on the local neiwoi k, the DDP builds the extended header of Figure 
DDP4 and calls the LAP to send the packet to a bridge (if there is more than one bridge, 
any one will do) on the local network. The bridges examine the destination network 
number of the datagram, and use routing tables to forward the datagram (through the 
LAPS of appropriate intervening local networks to which the bridge is cminected) to 
subsequent bridges to get it to a bridge connected to the destinaticm network. There the 
datagram is sent to its destination node through the local network's LAP. 

Routing tables are maintained by bridges by using the Routing Table Maintenance 
Protocol (RTMP) discussed elsewhere. The routing tables indicate, for each network 
number in the internet, the node ID (<xi the appropriate local network) of the next bridge 
on the proper route. 

Simple nodes (i.e. those that are not bridges) do not need to maintain these tables . 
Such nodes only need two pieces of information: the network number of the local network 
(THIS-NET). and the node ID of any bridge (A-BRIDGE) wi the local network. This can 


11-7 


7/20/84 




be done by implementing a simple subset of RTMP (called the RTMP Stub) in each such 
node. For nodes on systems consistir^ of a single AppleBus. the values of THIS-NET and 
A-BRIDGE are zero ("unknown"). 

Here is the internal routing algorithm for the DDF implementation module for a simple 
node (i.e. not an internet router). The sending client issues the send datagram call, 
specifying therein the destination socket’s internet address. Then the algorithm is as 
follows : 

If (Destination-Network-number • 0) OR (Destination>network>number « THIS-NET) then 
begin 

build the short-form DDF header; ' 

call LAP to send it to the destination node 
Old 
else 
begin 

build the extended-form DDF header; 
call LAP to send the packet to A-BRlDGE 
end 

For packets received by simple nodes from the LAP. the routing functim is simply one 
of delivering the packet to the destination socket in the node. It is advisable for such 
nodes to verify that the destination node ID and destinaticm network number in an 
extended DDF header in fact matches the stations node ID and network numbers. 

In internet routers, the algorithm is somewhat more complex. Details are provided in 
the discussion of the Routing Table Maintenance Protocol. 

tJ.6 RecommendMtions on the use of Sockets in Conjunction vrith Name Binding 

Implementations of AppleBus in commercial products must not rely on Statically 
Assigned Sockets. Apple has chosen this approach in order to provide a flexibile 
approach for developers without the need for a central administering body. 
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Developers should insteadd use the name binding technique to allow work stations to 
discover their server /service access point addresses. Thus developers would identify 
their server /service by a unique name. Workstations would then use NBP to bind an 
address to this name. [For details of this process see the document on the name binding 
protocol (NBP)]. Once the client process has determined the proper destination socket 
number, it can then proceed and transmit packets to that socket. 

A potential disadvantage of this approach is that developers must implement NBP in 
their servers. This is not significant for larger, complex^servers, but assumes 
importance for smaller memory-bound cases. In fact NBP has been so designed that a 
subset is all that is needed for such servers. This subset simply responds to Name 
Lookup packets received over the network. This subset does not need to implement 
general names table management, etc., since this table ctmtains Just a single name in it. 

n.7 DPP Checksum CoaputatiMi 

The 16-bit DDP checksum is computed as follows; 

1. CkSum :>0 : 

2. For each datagram byte starting with the byte immediately following the CkSum 
repeat the following algorithm : 

a. CkSum CkSum * byte; (unsigned addition) 

b. Rotate CkSum left one bit. rotating the most significant bit into the least 
significant bit. 

3. !f at the end, CkSum - 0, then CkSum hex FFFF (all ones). 

Reception of a datagram with CkSum ;• 0 implies that it is unchecksummed. 
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Figure 1X>P1 : Ap pleBus internet and bridges / internet-routers ( B ) 
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III. ROUTING TABLE MAINTENANCE PROTOCOL 


The Datagran Delivery Protocol introduced the concept of bridges or internet routers (IR). 

V 

It mentioned the mechanism by which datagrams are forwarded /routed, through intervening 
IRs. from any source socket to any destination socket on the internet. Mention was made of 
routing tables, maintained in the IRs, that were central to this routing mechanism. 

This section describes the ccmtent, establishment and maintenance of these routing tables 
by means of the Routing Table Maintenance Protocol (RTMP). Furthermore, it is through this 
protocol that any AppIeBus node can "discover* the number of the local network to which it is 
directly attached and the host ID of an internet router on its AppIeBus. 

III. 1 Bridges — Some Terminology : 

In general terms, a bridge is a device that can be connected to more thah one network for the 
purpose of serving as a datagram forwarding agent between those networks. Bridges are thus 
the key components in extending the datagram delivery mechanism to an internet setting. 

It is useful to distinguish the principal manners in which bridges may be used to build an 
internet of AppIeBus systems. Figure RTMPl illustrates the three major situations. 

Ca) Local Bridges: 

Configuration A shows a bridge used to interconnect several AppIeBus systems that are in 
close proximity (suchabridge might be said to beaiooa/bri4ge)- Such local IRs are connected 
directly to each of the AppleBuses they serve to bridge. They are useful in allowing the 
construction, within the same building, of an AppIeBus internet with more than 32 nodes. 

(b) Half Bridges: 

Configuration B illustrates the use of two bridges interccmnected by a long distance 
communication link. Each bridge is directly connected toan AppIeBus. The combination of the 
two bridges and the intervening link serves in effect as a bridgir^ unit between the AppIeBus 
systems. Each bridge in this unit will be referred to as a half bridge. The intervening link of 
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course can be made up of several devices, such as modems, and other networks, such as public 
data networks, etc. ‘nte primary use of half bridges is to interconnect remote AppleBus 
systems. An important characteristic of such bridges is that the throughput is in general 
lower than in the previous case, due to the lower speed of the communication link. 
Furthermore, usually these communication links display poorer error characteristics than the 
local networks of the internet. 

(c) Backbone Bridges: 

Although these might be placed in one of the previous^categories, they present an important 
set of properties that make it appropriate to single them out. These bridges are used to 
interconnect several AppleBus systems through a backbone network. Each bridge could be a 
local bridge connected (xt one side to an AppleBus. and on the other to the backbone network. 
This is illustrated as configuration C. Another manner of connecting a backbone bridge to the 
backbone network might be through a ]<xig-distance communication link. 

RTMP addresses these three important cases. A particular bridge might be a combination of 
two or more of the above as is indicated in configuration D. Thus the model of a bridge is general 
enough to allow for any of these four configurations . 

HI.2 BriiUns — A Model: 

We model a bridge as a device with several hardware ports, referred to as bridge porta, (see 
figureRTMP2) A bridge port can be connected in three ways: (a) directly toa local AppleBus 
( local bridge case) . (b) to one end of a ctMnmunication link the other end of which is connected 
to another bridge (half bridge ease), (c) either directly or via a communication link to a 
backbone network. In our model a bridge can have any number of ports, which are numbered 
starting with the number 1. 

Each bridge port has associated with it a port descript<^. This consists of three fields : (a) 
the port number, (b) the port node ID, ie the bridge’s node ID corresponding to that port, and 
(c) the port network number, ie the network number of the AppleBus to which the port is 
connected. The values of these three fields are obvious for a port that is directly connected to 
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a local AppleBus. For a port connected to erne end of a communicatiem link (half bridge case), 
the port node ID and port network number are both 0 ("unknown” ). For a port connected to a 
backbone network, the port network number is 0 ("unknown"), while the port node ID is the 
appropriate node ID of the bridge on the backbone network. In this latter case, provision must 
be made for this field to be of any size ( possibly variable length) depending on the nature of the 
backbone net. 

It is important to understand that the AppleBus node ID of a local bridge is different for each of 
its ports. Put another way, for each AppleBus to which iHs directly connected, the bridge 
acquires a different AppleBus node ID. 

Returning our attention to figure RTMP2, the bridge internals can be modelled as a suitable 
link access process for each port, a router, the routing table, and the routing table 
maintenance process implemented on a statically-fassigned socket known as the RTMP socket 
(socket number - 1 ). The router accepts incenning datagrams from theLAPs and then reroutes 
them out through the appropriate port depending on their destination network number. This 
routing decision is made by the router by ccmsulting the routing table. The routing table 
maintenance process receives RTMP packets, from other bridges, through the RTMP socket 
and uses these to maintain / update the routing table. 

III. 3 Routing Tables: 

All bridges maintain complete routing tables that allow them to determine how to forward a 
datagram on the basis of its destination network number. The RTMP protocol allows bridges to 
periodically exchange their routing tables and thus respond to changes in the cmnecti vity of 
the internet. Examples of changes are the installation or switching on of a new bridge, or its 
going down. 

A routing table that has stabilized to all changes will consist of one entry for each reachable 
network in the internet. Each entry provides the number of the port through which packets 
for that network must be forwarded by the bridge, the node ID of the next IR/ bridge, and a 
measure of the "distance" to the destination network. The entry in the routing table 
corresponds to the shortest path (known to that bridge) for the corresponding destination 
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network. The distance corresponding toa network to which the bridge is directly connected is 
always zero. 

This distance to a network is measured in terms of "hops”, each hop representing one 
IR ' bridge that the packet will encounter in its path from the current bridge to the destination 
network. This simple measure of distance is adequate for an RTMP that responds to the 
connectivity of the network and adapts to changes in this aspect. 

[Other modified measures could reflect the speeds /capacities of the intervening links and 
thus try to find a minimum time path. Yet another enhancement might use current traffic 
conditions on a particular path to modify its contributim to distance. This makes the routing 
tables adapt to traffic patterns and conditions. We have, for reasons of simplicity, chosen to 
use the hop-count measure. The basic algorithm remains unchanged if more complex measures 
are used.] 

A bridge receiving the routing table of another bridge compares it with its own table and 
updates the latter to record the shortest path for each destination network. 

Each table entry has associated with it an entry state value. This is a variable which takes on 
one of three values : good, suspect, bed. The significance of the entry state will become clear 
when the table maintenance mechuiism is discussed in more detail. 

Figure RTMP3 illustrates a typical routing table for a bridge with three ports in an internet 
consisting of seven networks. The corresponding port descriptors are shown in the figure as 
well. 

III.4 Routine TebleMeintenence — ConceptueJ description: 

Bridges do not have any knowledge of the topology or connectivity of the internet. Thus, the 
system must provide a mechanism that allows them to construct their routing tables and to 
maintain them in the face of changes in the internet (bridges coming up or going down). There 
are two parts to this process : initielization of the routing table, and its maintenance. 
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When a bridge is switched on. it initializes its table by examining the port descriptor of each of 
its ports. Any port with a ribn-zero port network number signals that the bridge is directly 
connected to that network. Thus an entry is created in the table for that network number . with 
a distance of zero and with that port’s number in the appropriate part of the entry. This initial 
table is called the routing seed of the bridge. 

Every bridge must periodically broadcest one or more RTMP packets through each of its ports. 
addressed to the RTMP socket. Thus every bridge’s routing table maintenance process will 
periodically receive RTMP packets from every bridge on its directly connected networks, 
backbones or communication links. The RTMP packets (see figure RTMP4 ) carry the port 
node ID and port network number of the bridge port through which the RTMP packet was sent, 
and the <network number, distance> pairs (such pairs are called routing tuples ) of the 
entries in the sending bridge’s routing table. With these RTMP packets the routing table 
maintenance process adds toor modifies its own routing table. 

The basic idea is that if an RTMP packet ( received by the bridge) ctmtains a routing tuple for a 
network not in the bridge’s table, then an entry is added for that network number with a 
distance one larger than the tuple’s distance. In essence, the RTMP packet indicates that a 
route exists to that network tluougli UieRTMP packet’s sender. 

Likewise, if an RTMP packet indicates a shorter path to a particular network than the one in 
the bridge’s routing table (ie if the tuple distance t plus one is less than the table entry's 
distance), then the corresponding entry must be modified to indicate the RTMP packet’s 
sender as the next IR for that network with the new distance. 

Clearly, this process allows for the growth and adaptation of routing tables to the addition of 
bridges! routes. 

* Aging” Routing Table Entries : 

However, if bridges die or are switched off. the corresponding changes will not be discovered 
through the foregoing process. To respond to such changes, the entries in the routing tables 
must be "aged” and, in the absence of confirmatim via new RTMP packets, be declared 
’’ suspect” and later ”bad” . Bad entries are purged from the routing tables. 
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Each entry in the routing table (corresponding to a network to which the bridge is not directly 
connected) was obtained from an RTMP packet received by the bridge from the next IR for that 
network. The RTMP protocol considers such an entry to be valid for a limited amount of time 
only (entry velidlty time ). Before starting the validity timer, the bridge goes through its 
routing table and changes the state of every 'Good" entry to "Suspect*. An entry must be 
revalidated from a new RTMP packet before the timer expires. 

Let us suppose for instance that the next IR, for a particular entry in bridge B's routing table, 
dies. Then, that IR will not be sending RTMP packets, ie the entry's validity timer will expire 
and bridge B will not have received confirmation of th^entry. At that time the entry's state is 
changed from "Suspect* to"Bad". Now any other RTMP packet received with path information 
to the network of the entry can be used to replace the entry with the new values from that 
pac ket . If no new route is discovered, then the bad entry will be deleted when the validity timer 
goes off a second time. 

More precise understanding of this process is available from the algorithms provided later in 
this chapter. 

III. 5 RTUPPecketFormt: 

Each bridge’s RTMP process must periodically send out its routing table information through 
each bridge port. This is broadcast as one or more datagrams addressed to the RTMP socket. 
Figure R TMP4 illustrates the RTMP packet. Clearly, the datagram need use only the short form 
of the DDP header. The DDP type field is set to 1 to indicate that it is an RTMP packet. The DOP 
data part of the packet consists of three parts : 

Sender's Network Number : 

The first two bytes of the RTMP packet's DDP data is the port network number from the port 
descriptor (of the port through which the packet is sent by the bridge). This field allows the 
receiver of the RTMP packet to determine the number of the network through which the pacekt 
was received. This is thus the number of the network to which the corresponding port of the 
receiver is attached. 

Sender's Node ID: 
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This field follows the sender’s network number field. It contains the port node ID from the port 
descriptor (of the port through which the packet is sent by the bridge). To allow for the case 
of ports connected to backbone networks other than AppleBuses, this field must be of variable 
size. The first byte of the field contains the length (in bits) of the sender node’s ID. This is 
followed by the ID itself. If the length of the ID in bits is not an exact multiple of 8 then we 
prefix it with enough zeros to make a complete number of bytes. The bytes of this modified ID 
are then packed into the ID field of the packet, most significant byte first. It is from this field 
that the receiver of the RTMP packet determines the ID of the bridge sending the packet. 

Routing Tuples: 

The last part of the RTMP packet consists of the routing tuples from the sending bridge’s 
routing table. The are <network niimber. distance> pairs with two bytes for the network 
number and one byte for the distance. 

For internets with a large number of AppleBusses, the entire routing table may not fit in a 
single datagram. In that case, the tuples are distributed over as many RT^ packets as are 
necessary. 

in. 6 Table IrUtiMlizs tion andMaintmance Algorithms : 

Vt'e discuss these in two parts : initialization first, and maintenance later. 

Routing Table Initialization : 

A bridge upon being switched on perf orms the following algorithm : 

For each port of the bridge 

If the port network number O 0 then create an entry for that network number 
with distance zero and the entry port number • the port. 

This algorithm creates an entry for each network to which the bridge is directly connected . 

Routing Table Maintenance : 

The bridge is assumed to have two timers running continuously. These are the vtlidity timer 
and the send-RTMP timer. The events to which the bridge’s RTMP process responds are: 
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RTMP packet is received, the validity timer expires, the send-RTMP timer expires. The 
corresponding algorithms are given below: 

(i) RTMP packet is received through port P : 

The following algorithm is executed : 

If port F *s port network number is zero then 

port network number : > RTMP packet's sender network number: 

For each routing tuple in the RTMP packet do 

If there is an entry in the routing table corresponding to the tuple's network 
number then U pdate-the-Entry else Create-New-Entry; 

Update-the-Entry and Create-New*Entryareas follows : 

U pdate-the-Entry : 

If (Entry-State -Bad) then 

If (tuple distance < 15) then Replace-Entry 
else 

If Entry's distance >- ( tuple distances 1) then Replace-Entry 

else 

If Entry's next IR - RTMP packet's sender node ID that 
Begin 

Entry distance : -tuple distance 4- 1; 

If entry distance <16 then 
Entry state :-Ckx)d 

else 

Entry state :-Bad 

End; 


Create-New-Entry : 

Entry's network number .‘-tuple's network number: 
Replace-Entry: 

Replace-Entry : 

Entry's distance :-tuple'sdistance-^l; 

Entry's next IR : - RTMP packet sender* s ID; 
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Entry's port numjaer : - P; 
Entry's state :«Good; 


(ii) Val idity Timer Ex pires : 

In this case the algorithm is as follows : 

For each entry in the routing table do 
Case Entry State of 

Good: If entry distance <> 0 thoi Entry state :>Suspect: 

Suspect: Entry state :• Bad: » 

Bad : Delete the entry 

End: 


(iii) Send-RTMP Packet Timer Expires : 

Now the following algorithm is executed : 

If routing table is not empty then 

Begin 

Copy the network number and distance pairs of each Good or Suspect entry of 
the routing table into the routing tuple fields of the RTMP packet: 

For each bridge port do 
Begin 

Packet's sender network number :- port network number: 

Packet's sender node ID :> port node ID: 

Call DDP to broadcast the packet through the port's LAP to the 
statically-assigned RTMP socket; 

End 


III. 7 How networks acquire theirnumbers : 

One of the major problems is how to administer and assign numbers to the networks in an 
internet. The basic idea we are proposing is that the network numbers are set Into the port 
descriptors of the bridge ports, and are then dynamically propagated out through RTMP to the 
other nodes of each network. 
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Not all bridges on a particular network must have the network number set into their 
corresponding port descriptors. The precise requirement is that at least one bridge (called 
the seed bridge ) on a network should have the network number built into its port descriptor. 
The other bridges could have a port network number value of 0. These will acquire the correct 
network number by receiving RTMP packets sent out by the seed bridge. 

An absolute requirement is that the bridges on a particular network should not have (in their 
port descriptors) conflicting port network numbers for that network. (The value zero does 
not causes conflict). 


ill.8 Whar part of RThlP do ordinary nodes have to implement? 

Nodes that are not bridges do not need to maintain routing tables. As noted in the chapter on 
DDP. these nodes only need to know the number of the network to which they are connected and 
the node ID of any bridge on that network. We referred to these quantities as THIS-NET and 
A>BRIDGE. 

When such a node Hrst comes up the values of both of these variables are zero (” unknown”). 
These nodes can obtain the correct values dynamically by listening for RTMP packets being 
sent out by the bridges on the network. For this purpose these ordinary nodes implement a 
very trivial RTMP process. This process sits on the RTMP socket in that node, and upon 
receiving an RTMP packet, copies the packet’s sender network number And sender node ID 
fields into THIS-NET and A-BRIDGE respectively. This is done every time an RTMP packet is 
received. Thus although THIS-NET will stabilize to a cmstant value. A-BRIDGE will 
constantly be changing ( if there is more than one bridge cm the network) . 

An optional extension can be made that ages the values of THIS-NET and A-BRlDGE just as in 
the case of a bridge’s routing table «itries. This might be important in the case of a node on a 
network that has only one bridge. Now, if that bridge goes down or is switched off, the node 
must discover that event through the aging mechanism. When starting the node’s validity 
timer, its THIS-NET and A-BRIDGE values, if gocxl. are declared to be suspect. Now if the 
timer goes of f and these values have not been confirmed from an RTMP packet then they become 
bad: when the timer goes off and the values are still bad then they are both reset to zero 
("unknown” ) and marked as bad. When updating these values from an RTMP packet the values 
are marked as good. 
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111.9 Values for the VMlidityandSend-RTMP Timers : 


These values have a significant effect on the dynamics of the propagation of routing table 
adaptation in response to changes in the internet’s connectivity. The exact values of these 
parameters will be determined by tuning actual internets and will be published at that time. 
For the present we propose to use a value of 5 seconds for the Send~RTMP timer and about 1 0 
seconds for the Validity timer. Since these values do not affect ordinary nodes in any 
fundamental way. the impact of changes will impact bridges only. 

III. 10 Bridges — the Routing Algorithm : 

Having established the appropriate terminology we can now spell out the details of the routing 
algorithm used by a bridge to forward internet datagrams. This discussion applies (xily to the 
forwarding of packets received by the bridge through one of its ports, ie it does not hold for 
packets generated within the bridge. 

Furthermore we assume that when a packet is received through one of the 
bridge ports, it is tagged with the number of the port and placed in a queue. The router takes 
packets off this queue and executes the algorithm in the flow chart of figure RTMP5. 
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IV. NAME BINDING PROTOCX)L 


IV. 1 Terminology 

AppleBus protocols rely on numerical identifiers, such as node IDs, socket numbers and 
network numbers, to provide the basic addressing capability essential for communication 
over a packet-switched network. These addresses are efficient and easily handled by the 
system's protocol software and hardware. However, human users of a network do not find 
numbers the most convenient form of identification. Numbers are hard for them to 
memorize and are easily confused and misused. Names are more easily used by the human 
user. Thus, if they are allowed to refer to objects by their names, the name must be 
converted into a network address for use by the other protocols. The Name Binding 
Protocol (NBP) performs this conversion. 

.Applebus uses dynamic node id assignment, which does not allow building in (or configuring 
in) addresses into software for accessing network resources. The name binding approach 
provides the preferable solution towards thes end. (see section II. 6) 

Network-Visible Entities : 

VTe start by defining the concept of a network-visible entity. In informal terms this is 
any entity that can be accessed over the network. More specifically, the socket clients on 
an internet are its network-visible entities (NVE). 

In this context we should make it clear that the nodes of the network are not 
network-visible entities. Rather, any services in the nodes available for access over the 
network are network-visible entities. Consider for instance a print server on a network. 
The server is not the network-visible entity. The print service will typically be a socket 
client on what might be called the server's request listening socket. The latter is the 
server's network-visible entity. 

The same distinction applies to the human users of the network. They are not 
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network- visible themselves. But a user may have an electronic mailbox on a mail server. 
This mailbox is network-visible and will have a network address. This distinction is 
quite valid, since the network does not provide any protocols for conversing with the 
individual user, but rather to certain applications /services through which the user may 
be accessed. 


Entity Names: 

Network-visible entities may assign names to themselves, though not all NVEs have 
names. Such a name will be called simply an entity name (EN). Entity names are 
character strings. A particular entity could in fact possess several names (.aliases ). 

In addition to a name, an entity could also have certain attributes. For instance, a print 
server's request receiver might have associated with it a list of attributes of the printer, 
such as its type (daisy wheel, dot matrix, laser), the type and size of paper, etc. So the 
mapping of the EN into its socket address might be complemented with some form of entity 
attributes "look-up" service. 

In defining the permissible structure of an entity name, we have decided to code the 
attributes into the name as a separate field, known as the entity type. 

In addition to attributes, it might prove useful to have some logically-defined location 
information about the entity. For instance, a given file server might belong to a 
particular department or building. The users of- the network should be able to select a 
file server on the basis of its being in the vicinity or in their department, etc. Thus, the 
concept of a zone has been defined by us and a zone field included in the entity name. A 
precise definition of the concept of a ztme is provided later. 

Thus, an entity name is a character string consisting of three fields: object, type, and 
zone concatenated together in this order with colon and Q-sign separators. For example. 
Sidhu:Mailbox0Bandley3. Each field is an alphanumeric string of at most 32 characters. 

Certain meta-characters can be used in place of explicit strings. For the object and type 
fields, an can be substituted, signifying 'all possible values' (wildcard). For the zone 
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field, a may be substituted, meaning the default value (the zone in which this node 
resides). If a network name does not contain any meta-characters, it is said to be fully 
specified. As an example. «:MailboxC* refers to all mailboxes in the same zone as the 
information requester. Likewise. would mean all named entities of all types in the 
requester's zone. Again, Sidhu:-i9* refers to all entities named Sidhu in the requester’s 
zone regardless of their type. 


Name Binding 

Before a named entity can be accessed over an AppleBus or an AppleBus internet, the 
address of that entity must be obtained. This is done by a process known as name 
binding. 

Name Binding may be visualized in several entirely equivalent ways ; as a mapping of an 
entity name into its internet address, as a lookup of the address in a large data base. etc. 
Both characterizations are used in our discussion of NBP. [Note: we will refer to the 
entity's internet address. This includes the case of a single AppleBus, where the 
network number field will always be equal to zero ("unknown” ).) 

Name binding can be done at various times. One strategy is to configure the address of 
the named entity into the system trying to access that entity. This so-called static 
binding is not appropriate for systems such as AppleBus where the node ID can change 
every time a node comes up. 

It is useful in this context to remember that although entities can move on a network, 
their names seldom change. For this reason, it is best to configure names into systems, 
and then use services such as NBP to bind dynamically. This may be done when the 
user /accessor's node is first brought up (known as early binding) or just before the 
access to the named entity is performed (known as late binding). Early binding runs the 
risk of using incorrect (out-of-date) information when the resource is actually accessed, 
possibly long after the user's node was brought up. However since the binding process 
might be a slow one, late binding might impinge unfavorably upon the response obtained 
by the user when accessing the named entity. Late binding is the method most 
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appropriate when the entity is expected to "move" on the internet. 


IV. 2 AppleBus Name B incline 

AppleBus Names Directory and Names Tables 

Name binding is done on AppleBus by using NBP to look up the entity's address in 
AppleBus' Names Directory (ND). This is a distributed data base of entity name to entity 
address mappings. The data base does not require different portions to be replicated. It 
can be distributed among all nodes containing named NVEs. NBP places no restriction on 
the use of name servers, nor are such servers necessary. 

The ND is the union of individual names tables (NT) in the nodes of the internet. Each 
node maintains in its names table the name-to-address mappings of all entities located in 
that node. As a consequence of this, name lookup performed on names corresponding to 
entities which reside on a node that is down or unreachable will fail. 

Aliases and Enumerators 

NBP allows an NV'E to have more than one name. Each of trhese aliases must be 
included in NT as an independent entity. 

To simplify and speed up the ability to distinguish between multiple names associated 
with a given socket, an enumerator value is associated with each NT entry. This is an 
8-bit integer, totally invisible to the clients of NBP. Each NBP implementation can 
develop its own scheme for generating enumerator values to be included in its NT, subject 
to the condition that no two entries corresponding to the same socket have the same 
enumerator value. 

Names Information Socket 

Each node implements an NBP process on a statically-assigned socket (socket number « 

2) known as the names information socket (NIS). This process is responsible for 
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maintaining the node's names table, and for accepting and servicing name lookup requests 
from within the node and from the network (through the NIS). 


Name Binding Service 

The name binding service consists of the following; 

(a) Name Registration : 

Any entity can enter its rtame and socket number into the ND (actually into its node's NT) 
to make itself "visible by name". This is done by using the name registratim call to the 
node's NBP process. 

This process must first verify that the name is not already in use. This is done by 
performing a name lookup in the node's zone. If the name is already in use. the 
registration attempt is aborted. Otherwise, the name and the corresponding socket 
number are inserted into the node's names table. This enters the corresponding 
name-to-address mapping in the ND. 

When a node comes up. its names table is empty. Each network visible entity must 
re-register its name(s) when restarted. 

(b) Name Deletion : 

A named entity should delete its name-to-address mapping from the ND when it wishes to 
make itself "invisible". Reasons for doing so range from the obvious one of the entity 
wishing to terminate operation to sophisticated entity-specific control requirements. 

The entity issues a name deletion call to the node's NBP process. The latter simply 
deletes the corresponding name-to-address mapping from the node's NT. 

(c) Name Lookup : 

Before accessing a named entity, the user (or a surrogate application) must perform a 
binding of the entity's name to its internet address. This is done by issuing a name 
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lookup call to the user node's NBP process. The latter then uses the NBP to perforin a 
search through the ND for the named entity. If it is found, then the corresponding 
address is returned to the caller. Otherwise an "entity not found" error conditi<m is 
returned. 

It is possible to find more than one entity matching the name specified in the call. This is 
especially true when the name includes the wildcard. The interface to the user must 
have provisions for handling this case. 

Another feature of NBP is that it does not allow abbreviated names; for instance, it does 
not permit reference to Sidhu: Mailbox. The complete reference Sidhu:MaiIbox6Bandley3 
or Sidhu :Mailbox0* is required by NBP. Provisions may be made in the user interface to 
permit abbreviations: the interface must then "flesh out" the name before passing it on to 
NBP. 

(d) Name Confirmation : 

Name lookup performs a zone-wide ND search. More specific confirmation is needed in 
certain situations. For instance, if early binding was performed, the binding must be 
confirmed when the named entity is actually accessed. For this purpose, NBP has a name 
confiraation call in which the caller provides the full name and address of the entity. 

This call in effect performs a name search in the entity's node to confirm that the 
mapping is still valid. 

Although a new name lookup can lead to the same result, the confirmation is much cheaper 
in terms of total network traffic generated. It is the recommended and preferable call to 
use when confirming mappings obtained through-early binding. 


Now we examine the binding protocol first for the case of a single AppleBus and later for 
the internet /multi-zone case. 
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IV.3 NBPonaSineleAppleBus 


Name searching /look-up is quite simple on a system consisting of a single AppleBus. We 
single out this case, since it is expected to be the most common instance of an AppleBus 
system, and because It serves to introduce the basic search technique. 

NBP relies heavily on the ability to broadcast packets on an AppleBus. The lookup 
proceeds as follows. 

The user issues a name registration or lookup request to the NBP process in its node. 
This process first examines its own names table to determine if the name is available 
there. If so. in the case of a registration attempt, the call is aborted with a "name already 
taken" result. For the case of a name lookup, the information in the names table is a 
partial response (there may be entities in other nodes that match the specified name). 

The NBP process now prepares an NBP lookup packet (LkUp packet } and then calls DDP 
to broadcast it over the AppleBus for delivery to the Names Information Socket. Only 
nodes that have an NBP process will have this socket activated. In these nodes the LkUp 
packet is delivered to the NBP process which searches its names table for a potential 
match. If no match is found then the packet is ignored, else a LkUp reply packet is 
returned to the address from which the LkUp packet was received. This reply packet 
contains the matching name-to-address mappings found in the replying node's names 
table. 

The receipt of one or more replies allows the requesting NBP process to compile a list of 
name-to-address mappings for the original user.. If the lookup was performed in 
response to a name registration call, then the call must be aborted as the name is already 
taken. 

Since broadcasts are not very reliable, the requesting NBP process sends the LkUp 
packet several times before returning the compiled mappings, if any. to the requesting 
user. If no replies are received, then it is concluded that there is currently no entity 
using the specified name. For a name lookup call, the user is informed of a "no such 
entity" outcome. For a name registration call, the requested name-to-address mapping is 
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entered into the node's names table. 

Sending the LkUp packet several times implies that the same name-to-address 
mapping could be received by the requesting node several times in LkUp-Reply packets. 
These duplicates must be filtered out of the list of mappings. The obvious way is to see 
if the mapping is already in the list , i.e. compare the name strings and the address fields 
with each entry in the compiled list. This method is inefficient. Comparison of the four 
byte address fields is insufficient because of the possibility of aliases. The enumerator 
value together with the address resolves this problem and accelerates the duplicate 
filtering. 

Name confirmation is similar in nature, except that the caller provides the name-to-address 
mapping to be confirmed. The LkUp packet is not broadcast but is sent directly to the NIS at 
the specified address. This can be repeated several times to protect against lost packets or 
the target node being temporarily busy. 


rv.4 NBPon an Internet 

The use of broadcast packets to perform name searching is inconvenient in internets. 
DDP does not allow a destination address corresponding to a broadcast to all nodes in the 
internet. DDP can broadcast datagrams to all nodes of any single specified network in the 
internet (these are said to be directed broadcasts'). If NBP sent a directed broadcast to 
every network in the internet, the traffic generated would be considerable. 

On AppleBus internets we provide for the formation of zones. NBP name searches are 
restricted to the nodes in a zone. 


Zones 

The AppleBus internet can be split up into zones. A zone consists of a subset of the 
AppleBuses in the internet. 

The individual AppleBuses in a particular zone need not be in any way contiguous or 
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"neighbors". A zone is an arbitrary subset of the buses in the internet. A particular 
AppleBus belongs to exactly one zone. The union of all zones is exactly the internet. 

The concept of zones is provided to assist the establishment of departmental or other 
user-understandable groupings of the entities of the internet. Zones are intelligible only 
to the NBP (and to the related Zone Information Protocol discussed elsewhere). 

A zone is identified by a string of at most 32 characters. 


Name Lookup on an Internet 

Bridges participate in the name lookup protocol of an internet. 

The NBP process in the requesting node prepares an NBP "broadcast request" packet 
(called a BrRg packet) and sends it to the NIS of A-BRIDGE. The NBP process in the 
bridge, in cooperation with the NBP processes in the other bridges of the internet, 
arranges to convert the BrRq packet into one LkUp packet for each AppleBus in the 
target zone of the lookup request. Each of these LkUp packets is then sent to the NIS 
socket as a directed broadcast on the corresponding AppleBus. The replies are returned 
to the original requester as before. 

The important point is that ordinary nodes (other than bridges) do not have to know 
anything about zones. The process of generating a zone-wide broadcast is done by the 
collection of bridges. The latter must of course' jointly have a complete mapping of zone 
names into the list of corresponding AppleBuses. The establishment and maintenance of 
these lists is the purpose of the Zone Information Protocol discussed elsewhere. 


IV.5 NBP Interface 

Four calls provide to the user all the functionality of name binding. They are as follows : 
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(n REGISTER-NAME 


This call is used by an NBP client to register an entity name and its associated socket 
address. Except for a default zone specification, meta-characters are not allowed in the 
name. If a is not used, the zone field must be the same as the default. 

Call Parameters : 

entity name, 
socket number 

Returned Parameters : 

outcome code: success 

failure (name conflict, invalid name or socket) 


(2) REMOVT-NAME : 

This call removes an entity name from the node's names table. Meta-characters are not 
allowed in the name. 

Call Parameters : 
entity name 

Returned Parameters : 
outcome code: success 

failure (name not found) 

List of fully specified entity names and their corresponding AppleBus 
addresses 


(3) LOOKUP-NAME: 
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This call performs the mapping between entity name and address. Meta-characters are 
allowed in the name to make the search as general as needed. It is possible for more than 
one AppleBus address to match the call's entity name and be returned. The 
corresponding fully-specified name is returned to the caller as well. 

Call Parameters : 
entity name 

maxMatches 

Returned Parameters : 

outcome code; success 

failure (name not found) 

List of fully specified entity names and their corresponding 
AppleBus addresses 

The parameter maxMatches is a positive integer that specifies the maximum number 
of matching name-to-address mappings needed. This is useful if wildcards are used 
by the caller in the entity name parameter. 

(4) CONFIRM-NAME : 

This call confirms a caller-supplied mapping between entity name and address. 
Meta-characters are not allowed in the name. 

Call Parameters : 
entity name, 
socket address 

Returned Parameters : 

outcome code ; success (mapping still valid ) 
failure (mapping invalid) 
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IV.6 NBP Packet Formats 


All NBP packets use a DDP type field value of 2. 

There are three different types of NBP packets; BrRq. LkUp and LkUp-Reply. The 
format is as shown in Figure NBPl. The various fields of the NBP part of these packets 
are as follows : 

Control 

The most significant four bits of the first byte are used to indicate the type of NBP 
packet. The values are 1 for BrRq, 2 for LkUp and 3 for LkUp-Reply. 

Tuple Count 

The packets contain name-address pairs called SBP tuples (see figure NBP2). The least 
significant four bits of the first NBP byte contain a count of the number of tuples in that 
packet. 

BrRq and LkUp packets carry exactly one tuple (with the name being looked up or 
confirmed). The tuple count field for these packets is always equal to 1. 

NBP ID 

In order to allow for multiple pending lookup requests from a given node, an 8-bit ID is 
generated by the NBP process issuing the BrRq or LkUp packets. The LkUp-Reply 
packets must contain the same NBP ID as the LkUp or BrRq packet to which they 
correspond. 

Requester's Address 

BrRq and LkUp packets include the 4-byte address field of the NBP tuple, which 
provides the complete internet address of the requester. This field allows the responder 
to properly address the LkUp-Reply datagram. 
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NBP Tuple 


The NBP tuple consists of an entity's name and its 4-byte internet address and a one-byte 
enumerator field. The address field appears first in the tuple. The fifth byte in a tuple 
is the enumerator field, followed by the entity name. This consists of three string fields ; 
one each for the object, type and zone names, in that order. Each of these strings 
consists of a leading 1-byte string length followed by up to 32 string bytes. The string 
length represents the number of bytes /characters in the string. The three strings are 
concatenated without any intervening padding. 

Enumerator Field 

This field is included to handle the situation where more than one name has been registered on 
the same socket. It should be noted that NBP specifically permits this use of aliases (or 
alternately, the useof a single socket by more than one NVE). 

In this case, each alias is given a unique enumerator value, kept in the NT along with the 
name-address mapping. The enumerator field is not significant ina LkUp or BrRq packet, and 
is ignored by the recipient of these packets. (Recall that the address part of the tuple, in this 
case, is the requester's address). 

In a LkUp-Reply packet, the correct enumerator value must be included in each tuple. This 
value is used for duplicate filtering. 
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One Byte (8 bits) . 

Network 

Number 

Node ID 
Socket Number 
Enumerator 

Object Field Length 
Object 

Type Field Length 
Type 

Zone Field Length 


Zone 









VI. APPLEBUS TRANSACTION PROTOCOL 


The AppleBus Transaction Protocol (ATP) is a transport protocol that adequately 
fulfills the transport needs of the vast majority of peripheral devices, and satisHes the 
transaction needs for more general networking on AppleBus. Our goal has been to strike 
a compromise between features needed for networking and for peripheral device control. 
Particular attention has been paid to simplicity and ease of implementatim, so that nodes 
with tight memory space restrictions will be able to support a sufficient subset of ATP. 

VI. J Introduction 


The fundamental purpose of reliable transport protocols is to provide loss>free 
delivery of client packets from source socket to destination socket. Various features can 
be added to this basic service, to obtain the service characteristics appropriate for its 
specific needs. Transport characteristics can be added by clients or built into standard 
value-added transport services. ATP is such a value-added service. 

Transactions - Terminology : 

Frequently, a socket client must request the client of another socket to perform a 
particular higher level function and to report the outcome to the requester. This 
interaction, consisting of a request and a response, is termed a transection. 

The basic structure of a transaction, in the context of a network, is illustrated in 
Figure ATPl. A transactimi has a requesting end and a responding end. The requesting 
end initiates the transaction by sending a transection request, TReq, from the requesting 
end's socket to the responding end's socket. The responding end executes the request 
and returns a transaction response, TResp, reporting the transaction's outcome. 

At-Least-Once Transactions : 
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This basic process must be performed in the face of various situations inherent in the 
loosely-coupled nature of networks, fw example: 

(i) TReq is lost in the network; 

(ii) TResp is lost or delayed in transit; 

(iii) the responding end "dies" or becomes unreachable from the requesting end. 

in the first place, there could be several transaction requests outstanding, and the 
requesting end must be able to distinguish between the respective responses received by 
it over the network. This can be done by using a transaction ID (TID). sent with the 
request. The resptxise must contain the same ID as the corresponding request. The TID. 
in a sense, "binds” together the request and the response portions of a transaction. 

In every one of the above three error situations, the requesting end will not receive 
the transaction's response and must conclude that the transaction was not completed. A 
recovery procedure must then be activated at the requesting end. This consists of a 
timeout and an automatic retry mechanism, if the timer expires in the requesting end and 
the response has not been received, the requester retransmits the TReq. This process is 
repeated until a response is received or until a retry count maximum is reached. If the 
retry count hits its maximum value then it is excluded that the responding end is either 
"dead" or unreachable, and the transaction requester (the ATP client at the requesting 
end) is so notlHed. 

This mechanism does its best to ensure that the transactiem request is executed at 
least once. Such a mechanism is adequate if the request is essentially idempotent, e.g. 
repeated execution of the request is the same as executing it once. [An example of an 
idempotent transaction is asking a destination station to identify itself]. 

Exactly-Once Transactions : 

Nevertheless, with this recovery mechanism, lost or delayed responses could cause 
the transactiem to be executed more than once. If the request is not idempotent, serious 
damage could result. For such requests it is desirable to have a transaction protocol 
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which ensures transactiwi execution once and exactly once. 


Whether the at-leastHMice or the exactly-mce level of service is appropriate can only 
be determined by the transaction requester. 

The basic technique for implementing an exactly-once transaction protocol is as 
follows. The responding end maintains a transactions list of all recently received 
transactions. Upon receiving a TReq it searches through this list to determine if the 
request has already been received (duplicate transaction-request filtering). A new 
request is inserted into the list before being executed (and then a response is sent out). 
Upon receiving a duplicate request for which a response has already been sent, the 
responder retransmits the response. 

Upon receiving a TResp the requesting end should return a transaction release (TRel) 
packet to release the request from the responding end's transacticms list. If this TRel 
gets lost then the request would stay in the list "forever”. To eliminate this situaticm. 
the responding end "timestamps" a request before inserting it in its list. The list is 
checked periodically and requests that have been in it for too long are eliminated. 

Vt.2 AppleBus Transactia: Protocol — Multi-Packet Responses 

ATP uses the basic idea that a transaction is a request issued by a client in a 
requesting node to a client in a responding node. The client in the responding node is 
expected to service the request and generate a response. It is assumed that the two 
clients have some method of unambiguously identifying the data 'operation sought in the 
request (eg. read a disk block, block number, etc.). 

This is a very simple model, in principle sufficient for all interactions. The difficulty 
is that the underlying network places a size restriction on the packets that may be 
exchanged. Thus, for instance, the transaction response might not fit in a single packet. 
For this reason we look upon the transaction request and response as "messages" (not 
packets). Although ATP restricts its transaction requests to single packets, ft allows 
the transaction response message to be made up of several packets, which of course bear 
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a sequential relaticmship to one another. When the requesting node receives all the 
resptmse packets (i.e. the complete response message), the transaction is considered 
complete and the response is delivered as a single logical entity to the ATP client (the 
transaction requester). 

ATP supports both 'at-least-once' and 'exactly-once' modes as client-elected 
options. 

if the 'at-least-once' case is chosen then. ATP handles timeouts and retransmission of 
requests but does not attempt to prevent duplicate requests from being passed to the 
transaction responder. In this case, if request actions are not idempotent. it is up to the 
responding client to filter duplicates. 

The maximum size (number of packets) of a transaction response message is limited 
to 8 packets. 

Transactiwi IDs : 

Transaction IDs are generated by the requesting end and sent along with the TReq 
packet. An important design issue is the size (16 bits for ATP) of these IDs. This is a 
function of the rapidity with which transactions are generated and of the maximum packet 
lifetime (MPL) for the ctxnplete network system. The Icxiger the MPL the larger the TID 
must be. Similarly, if transactions are generated rapidly, then the IDs must again be 
larger. The basic problem is that the TID being of Hnite size wraps around and there is 
the danger that for a particular value an old packet stored in some internet router may 
arrive later m and be accepted as a valid packet. 

For a single AppleBus. the time taken for exchanging a TReq and a TResp is bounded 
(by the ABLAP) to be greater than about 2.S msec. Thus there can be no more than 400 
transactions per second. From this point of view a single byte TID would allow half a 
second or so for wraparound of the TID. 

However, with network interconnection through store-and-forward internet routers. 
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the impact of MPL (of the order of 30 seconds) makes a one-byte TID inadequate. A 
16-bit ID would increase the wrap around time to be approximately two minutes. This 
obviates all omncerns about old retransmitted transaction requests and responses 
* sneaking-in” due to wraparound. 

The ATP BitMao /Sequence Number; 

Every ATP packet includes in its header a b/tmep/aaquence number. This field is 8 
bits wide. ATP handles lost or out-of-sequence response packets by using this bitmap. 
The significance of this field depends on the type of ATP ^cket (TReq, TResp or TRel). 

In TReq packets this field is known as the tnuiaaetion bitmap. The basic idea behind 
the use of this field is that the requesting end reserves enough buffers for the expected 
transaction response, and then sends out the TReq packet indicating to the responder the 
number of buffers reserved. This is done by setting a bit in the TReq packet's bitmap, 
for each reserved buffer. The Msponding end can then examine the TReq packet's ' 
bitmap and determine the number of packets tlm requester is expecting to receive in the 
transaction response message. 

In TResp packets this field is known as the ATP aequenee number. The value of this 
field in the TResp packet is an integer (in the range 0 to 7), indicating the sequential 
position of that packet in the transaction response message. The requesting end can use 
this value to put the received response packet in the appropriate response buffer (even 
if the response packet is received ”out-of-sequence”) for delivery to the transaction 
requester (ATP client). Furthermore, the requesting end clears the corresponding bit in 
its transaction bitmap. 

The actual transaction response message may turn out to be smaller than was expected 
by the requester. Thus a provision is made in the response packet's header to signal 
”end-of-message” in the last response packet when it is sent out by the responder. Upon 
receiving a response packet with the end-of-message indication, the requesting end must 
clear all bits in the transacticn bitmap corresponding to higher sequential positions. 

If the requesting end's retry timeout expires and the complete transaction response has 
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not been received as yet (indicated by one or more bits still set to one in the requester's 
transaction bitmap), then a TReq is sent out again with the current value of the 
transaction bitmap and the same TID. Thus only the missing transaction response 
packets are requested again. 

This mechanism is illustrated in Figure ATP3 where a requesting end issues a TReq 
indicating that it has reserved six buffers for the response. For instance, the request 
might be for six blocks of information from a disk device. The TReq packet would have 
in its ATP data part the pertinent information: what file, which six blocks, etc. ATP 
builds the request packet and sets the least signiHcant six bits in the bitmap. When the 
responder receives this request packet, it examines the bitmap and thus determines the 
range of the host's request to be serviced. The six blocks are fetched from disk, passed 
to the ATP layer in the device node and sent back to the host, each in a separate packet 
with its sequence number indicating the position in the response. 

The example illustrated in the figure assumes that the third response packet is lost 
in the network. Thus the retry timeout will expire in the requesting «td. which then 
retransmits the original request (transparently to the ATP requestii^ client) but with a 
bitmap reflecting only the missing third response packet. 

Notice that single packet request>resp<»)se transactions are simply the degenerate 
case in which the transaction reqxjest has only one bit set in its bitmap. If two nodes wish 
to communicate in this manner, very little extra packet overhead is added by the 
protocol. 

Responders with Limited Btiffer Space: 

A potential difficulty with exactly-once transactions is that a responder might not 
have enough buffer space to hold the entire transactim response message until the end of 
the transaction (i.e. receipt of a TRel). 

ATP provides a mechanism for such responders to reuse their buffers, through a 
confirmatitm of response packet delivery. This is done by piggy>backing, in a response 
packet, a request to Send Transaction Status (STS). The requesting «id, upon receiving 
such a response packet, just immediately send out a TReq with the current bitmap (i.e. 
indicating *ch response packets have been received correctly). The responding end 
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can then use this bitmap^ to free buffers holding already delivered response packets. 

Figure ATP4 illustrates this with an example in which the respmding end, with two 
buffers, services a request for a seven packet response. 

TReq packets sent in response to an STS do not consume the retry count, but do reset 
the Retry TimeOut. 

Vl.3 ATP Details 


Details of the ATP protocol are provided in three parts: the packet format, the ATP 
interface, and the mechanism (state /action model of the ATP protocol package). 

ATP Packet Format 


The format of an ATP packet is illustrated in figure ATP5. It consists of an 8-byte 
ATP header plus up to 578 ATP data bytes. 

The first byte of the ATP header is used for command /control information (CCI). The 
two most significant bits of the CCI are the packet's function code. These two bits are 
encoded as follows : 


01 — TReq packet 

10 — TResp packet 

11 — TRel packet. 

The EOM bit is set in a TResp packet to signal that it is the last packet in the 
transaction response message. The XO bit must be set in all TReq packets that pertain 
to the exactly-<mce mode of operation of the protocol. The STS bit is set in TResp 
packets to force the requester to retransmit TReq immediately. The remaining three bits 
of CCI must always be 0. 

The 8 bits immediately following the command /control field contain the ATP 
bitmap /sequence number, with the most significant four bits in the first byte of the ATP 
header. The packets comprising the transacticm resptmse message are assigned sequence 
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numbers 0 through 7. The sequence number (encoded as an integer) is sent in the ATP 
bitmap /sequence number Held of the corresponding response packet. 

In the case of a transaction request packet, a bit of the bitmap is set to one for each 
expected response packet. The least significant bit corresponds to the response packet 
with sequence number 0. up through the most significant bit which corresponds to 
sequence number 7. 

The third and fourth bytes of the ATP header contain the 16-bit transaction ID. TIDs 
are generated in the ATP requesting end. and are incremented from transaction to 
transaction as unsigned 16 bit integers (the value zero is permitted). 

The last four bytes of the ATP header are not examined by ATP. but contain user data. 
As such, they should, strictly speaking, not be considered part of the ATP header. 
However, they can be used by the ATP clients to build a simple header for a higher level 
.protocol. The reason they have been separated out is to allow an implementation of ATP 

f 

that handles the complete ATP respcmse messages data in an assembled, contiguous, 
form, without interposed higher level headers. ATP-Client interfaces must build 
appropriate mechanisms for exchanging these four user bytes independently of the data. 

ATP Interface 

The interface to ATP is made up of the five calls described below. It is cmvenient to 
visualize the ATP package (an implementation of ATP) as consisting of two parts : the 
ATP Requesting end and the ATP Responding end. The calls are discussed in the ccmtext 
of each end. 

It is not appropriate in this specificatim of the protocol to detail the interface, as 
several aspects are implementation dependent. The description below is in general 
terms, adequate for establishing the characteristics of the ATP service to the next higher 
layer. 

Remember that we neither assume nor require the availability of a multiprocessing 
environment in the network node. Our descriptions of the various interface calls have 
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been written in a generic form indicating parameters passed by the caller to the ATP 
implementation, and results and outcome codes returned by the latter. The result codes 
and their interpretation depend on the specifics of the implementation of a call. If the 
call is issued synchronously, the caller is blocked until the calls operation has been 
completed or aborted, then the returned parameters become available when the caller is 
unblocked. In the case of asynchronous calls, a call completion mechanism is activated 
when the operation completes or aborts. Then the returned parameters become available 
through the completion routine mechanism. 


We envision at least two kinds of interfaces; a packet-by-packet passing of response 
buffers to and from ATP. and a response message (i.e. in a contiguous buffer) interface. 
These are analogous to the familiar packet stream and byte stream interfaces available for 
data stream protocols. Details of both types of ATP interfaces for Apple systems will be 
made available in application notes. 

1. ATP Requesting End Calls : 

Only one call is defined for use by the transaction requester. This call is processed 
by the ATP requesting end. 

(1.1) SEND-ATP-REQUEST : 

The transaction requester (ATP client) issues this call to send a transaction request. 
It must supply several parameters with the call. These include the address of the 
destination socket, the ATP data part of the request packet, buffer space for the 
expected response packets, and whether the exactly-<xice mode of service is required or 
not. In addition the caller can specify the duration of the retry timeout to be used and 
the maximum number of retries. 

Call Parameters: 

Transaction mode (exactly-once or at-least-once) 

Transaction Responder's address (network number, node ID 
and socket number) 
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Call Parameters (cont.): 

ATP request packet's data part and its length 
Expected' number of response packets 
Buffer space for the transaction response message 
Retry timeout in seconds 
Maximum number of retries 
Returned Parameters : 

Outcome code (success, failure) 

Number of response packets received 

The following situations return an outcome code of failure: 

- the caller requested exactly-mce service, but the responding end does not 
support it; 

. - ATP has exhausted all retries and a complete response has not been received. 

An outcome code of success is returned whenever a complete response message has 
been received. A complete response is said to have been received if eithbr of the 
following occurs: (i) all response packets originally requested have been received, or 
(ii) ail response packets with sequence number 0 to some integer n have been received 
and packet n had the EOM bit set. 

In either case, the actual number of response packets received is always returned to 
the requesting client. A count of zero should indicate that the other end did not respond 
at all. In the case of a nmzero count, the client can examine the response buffer to 
determine which portions of the response message were actually received and to detect 
missing pieces for higher level recovery, if so desired. 

2. ATP Responding End Calls : 

There are four calls that a transaction responder (ATP client) can make to the ATP 
responding end. 
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(2.1) OPEN-ATP-RESPONDING-SOCKET: 


An ATP client uses this call to instruct ATP to open a socket (well>known or 
dynamically assigned) for the purpose of receiving transaction requests. If well-known, 
the client passes the socket number to ATP: otherwise the dynamically assigned socket 
number is returned to the client. 

When opening this socket, the client is in effect opening a "transaction listening 
socket". The call allows the socket to be setup so that requests are accepted from a 
specified network address (provided in the call). This address can include a zero in the 
network number, node ID. or socket number fields to indicate that any value is acceptable 
for that field. 

Call Parameters : 

' Transacticm listening socket number (if well-known) 

Admissible transaction requester address (network number. 

node ID. and socket number) 

Returned Parameters : 

Local socket number (if dynamically assigned) 
outcome code (success, failure) 

Note that this call does not set up any buffers for the reception of transaction 
requests. That is done by issuing the Receive-ATP-Request call. 

(2.2) CLOSE-ATP-RESPONDINC-SOCKET : 

This call is used to close a socket opened with an OPEN-ATP-RESPONDING-SOCKET 
call. 

Call Parameters : 

Transaction listening socket number 
Returned Parameters : 
outcome code (success, failure) 
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(2.3) RECEIVE-ATP-REQUESY : 


The transection responder issues this call to set up the mechanism for actual 
reception of a transaction request through an already-opened transaction responding 
socket. 


Call Parameters: 

Local socket number on which to listen 
Buffer for receiving the request 
Returned Parameters; 
the received request's ATP data 
Transaction ID 

Transaction Requester's Address (network number, node ID and 
socket number) 

Bitmap 
XO indication 

(2.4) SEND-ATP-RESPONSE 

When a transaction responder has finished servicing the request, it issues a 
SEND-ATP-RESPONSE call to send out one or more response packets. ATP will send out 
each response buffer with the correct transaction ID and a sequence number indicating 
the position of the particular response packet in the response message. There are many 
different ways of implementing the call; our description is generic. 

Call Parameters: 

Local socket number (the responding socket) 

Transaction ID 

Destination Address (Network number, node ID and socket 
number) 

Transaction response message/ packets (ATP data part) 
descriptors to determine the sequence numbers of the response 
packets 

Call Parameters (cont.) 
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EOM and STS control 


Returned Parameters : 
outcome code: (success, failure) 

ATP State Model 


Management of STS will be discussed in a future version of this document. The 

\ 

following description provides a sufficiently precise statement of the protocol internals 
for the purpose of implementing the protocol. It is not a formal specification, but an aid 
for protocol implementers. 

The description is presented in terms of the actims to be taken in response to all 
possible events. [This description is subject to modification as we gain more 
experience through actual implemen^tion of the protocol: it is the current state of our 
understanding of the protocol and will not be widely different in subsequent updates.] 
Certain special terms are employed in the description, and we start with a discussion of 
some of these. 

First of all, the ATP requesting end must maintain all information necessary for 
retransmitting an ATP request and for receiving its responses. This is referred to by us 
as the Tnnsectitm Control Block (TCB). More specifically, this would cmtain all the 
information provided by the transaction requester in the SEND-ATP-REQUEST call, plus 
the TID, the request's bitmap and a response packets received counter. With each 
request and thus with each TCB we associate a retry timer, used to retransmit the request 
packet in order to recover fr(»n loss of request or response packet situatims. 

In the second place, the ATP resp<mding end must maintain a Request Cmtrol Block 
(RqCB) for each RECEIVE-ATP-REQUEST call issued by a client in that node. This call 
would contain the informatiwi provided by that call including all pertinent data as to the 
buffers and delivery-to-client mechanism (implementation dependent). 

A third data structure, the Response Control Block (RspCB) is needed only in nodes 
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implementing the exactly-once mode of operation. It holds the information needed to filter 
duplicate requests and to retransmit response packets in respmise to these duplicates. 

We associate a release timer with each RspCB. This timer is used to release the RspCB in 
the event that the release packet sent by the requesting end is lost. 

1. ATP Requesting End: 

SENT)-ATP-Request call issued by a Transaction Requester in the Node: 

a. Validate the following call parameters: 

Number of response packets shouldjbe at most 8: 

the ATP Request’s Data should be at most hUxATPData bytes long. 

If either parameter is invalid, then reject the call. 

b. Create a TCB: 

- insert the call parameters in it 

- . clear the response packets counter. 

c. Generates TID: 

> this is the last used TID plus one modulo 2^^' 

Save the TID in the TCB. 

d. Generate the bitmap for the request packet and save it in the TCB. 

e. Prepare the ATP header: 

- insert the TID and the bitmap; 

- set the function code bits to 01: 

- (only for systems implementing the exactly-once mode of operation) if 
the caller requested exactly once mode the set the XO bit. 

f. Call DDP to send the ATP request packet. 

g. Start the request’s retry timer. 

Retry timer expires : 

a. If Retry Count • 0 then: 

- set outcome code to ’failure’: 

- notify transaction requester (the client in the node) of the outcome: 

- destroy the TCB. 
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b. If Retry Count <> 0 then: 

- decrement the retry count: 

. change the* bitmap in the ATP request's header to the current value in 
the TCB: 

- call DDP to retransmit the request packet; 

- start the retry timer. 

ATP Response Packet received from the network (i.e. from DDP) : 

a. Use the packet's TID and source address to search for the TCB: 

b. If a matching TCB is not found then ignore the packet and exit. 

c. If a matching TCB is found then check the packit's sequence number against 
the TCB's bitmap to determine if this response packet is expected. The 
packet is expected if the bit correspmding to the repcnse packet's 
sequence number is set in the TCB's bitmap. If the packet is not expected 
then ignore it. 

d. If the response is expected then: 

• clear the corresponding bit in the TCB bitmap: 

> set up response packet's ATP data for delivery to the transactim 

requester: 

- increment the response packets counter in the TCB. 

e. If the packet's EOM bit is set then clear all higher bits in the TCB bitmap. 

f. If the TCB bitmap - 0 then: (a complete response has been received) 

- cancel the retry counter: 

- set the outcome code to 'success': 

- (only if exactly-once mode is implemented) if the transaction is of 
cxactly-once mode (determined by examining the TCB) then call DDP to 
send a TRel packet to the responding end; 

> notify the transaction requester; 

- destroy the TCB. 

2. ATP Responding End : 

OPEN-ATP- Responding- Socket call issued by a Transaction Responder in the Node: • 
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A. If caller specifies a well-known socket then call DDP to open that socket else 
call DDP to open a dynamically assigned socket. 

b. If DDP returns with error then set outcome code to the error. 

e. If DDP returns without error then: 

- set outcome code to 'success': 

- save socket number and the admissible transaction requester address in 
an ATP responding sockets table. 

d. Return to caller. 

CLOSE-ATP-Responding-Socket call Issued by a Transaction Responder in the Node: 

a. Call DDP to close the socket. *' 

b. Release all RqCBs, and. for systems supporting exactly-once mode of 
operation, release all RspCBs (and cancel all release timers), if any. associated 
with the socket. 

c Delete the socket from the ATP responding sockets table. 

RECEIVE-ATP-REQUEST Call issued by the Transaction Responder in the node: 

a. If the specified local socket is not active then return to caller with errw. 

b. Create a RqCB and attach it to the socket. 

c. Save the call's parameters in the RqCB. 

SEND-ATP-Response call issued by transaction responder in the node : 

a. If the local socket is invalid OR response data lengths are invalid then return 
to caller with error. 

b. (only if exactly-once mode is implemented) Search for a RspCB matching the 
call's local socket number. TID. and transaction requester address (destination 
of the ATP Response). If found then save the response attached to the RspCB 
(for potential retransmissicm in resptxise to duplicate requests received 
subsequently), and restart release timer. 

c. Send the response packets, setting the ATP header of each with function code 
10. with the caller supplied TID. with the correct sequence number for the 
packet's sequential position in the response message, and with the EOM flag set 
in the last response packet. 


VI - 16 


7/20/84 





Release timer expires : {wily If exactly-once mode of operation is implemented} 

a. Destroy the RspCB and release all associated data structures. 

ATP Request Packet (TReq) received from DPP : 

a. (only if exactly-once mode is implemented) If the packet has its XO bit set and 
a matching RspCB exists then: 

- retransmit all response packets: 

- restart the release timer: 

- exit. 

b. if a RqCB does not exist for the local socket or if the packers source address 
does not match the admissible requester address in the RqCB then ignore the 
packet and exit. 

c. (only if exactly-once mode is implemented) If packet's XO bit is set then create 
a RspCB and start Its release timer. 

d. Notify the client about the arrival of the request and destroy the corresponding 
RqCB. 


ATP Release Packet (TRel) received from DPP : (tmly if exactly-mce mode is 
implemented) 

a. Search for a RspCB that matches the packet's TID and source address. If not 
found then ignore the release packet. 

b. If a matching RspCB is found then: 

- destroy the RspCB and all release all associated data structures. 

- cancel the RspCB' s release timer. 

VI.4 StMpe OptionMJ ATP Interftoe Calls : 

In certain instances the clients of ATP might use certain ccmtextual information to 
enhance their use of ATP through some additional interface calls. Here are two examples. 

Release-RspCB : 


VI - 17 


7/20/84 




In the first case.two clients of ATP are communicating with each other, using the 
exactly once mode, and iiave decided to have at most one outstanding transaction at a 
time. Client A calls ATP to send a TReq packet to client B. B sends back the response. 

A upon receiving the response sends out a second request (but no release packet). The 
second request packet upon being received by B signals that the response to the 
previous request has been received by A. Now B could simply call its ATP responding 
end and ask it to release the previous transaction's response control block. This needs a 
Release-RspCB call to the ATP responding end. The parameters of this call are fairly 
obvious in this instance. 

Release-RqCB: 

Another instance arises when a client A> wishes to send data to client B. A must Hrst 
inform B of this intention, and thus allow B to request the data. To this end. A can send 
a TReq to B to signal "I want to write N bytes of data to you. please ask me for it on my 
socket number S*. Instead of sending a TResp to this packet. B could just send a TReq 
to A's socket S asking for the data. The recepticxi by A. on socket S, of B's request 
implies that A's original request has been received by B. A could call its ATP requesting 
end and ask it to eliminate the previous transaction's RqCB. This needs a Release-RqCB 
call to the ATP requesting end. 

Details of these calls are implementation-dependent and do not affect the ATP protocol 
per se. We mention these as interesting variants that might be implemented by certain 
clients who wish to reduce the trafflc generated on the network. 
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Vll. DATA STREAM PROTOCOL 


The other important transport protocol Is for the transfer of sequences of packets or 
more generally sequences of data bytes. We group this into the single term data Btrmm. 

This is an area in which an enormous amount of work has been done in the networking 
community under the general terminology of connection-oriented protocols, virtual 
circuits, liaisons, etc. A wide ctxisensus has been arrived on the basic structure of such 
systems. Certain characteristics that stand out are the need for a symmetric protocol 
allowing full duplex data streams between a given pair of sockets, management of flow 
control by using credits sent by the intmided receiver to the sender, sequencing by the 
use of sequence numbers in each datastream packet, connection establishment through 
handshakes that coordinate the initial state of the two connection ends (and hence the 
connection). 

yy/.'l TeraifnoJQgy; 

We start by establishing the significance of certain terms and oxicepts. In particular, 
the ideas of a connection, of ccmnectimi ends and of connection IDs and their signincance 
play a central role in a data stream protocol. 

Cwinections and Connection Ends: 

A connection is an associaticm between a pair of sockets that allows the reliable, 
full-duplex flow of packets between them without loss or duplicate packet delivery. 
Packets are delivered in the same order that they were inserted into the connection. 
Futhermore, there is a flow control mechanism built into the protocol that regulates the 
sending of packets according to the availability ot buffers at the receiving mid. Other 
terms used to describe connections are virtnel drcuita, Ueiaona, etc. 

Connections can be set up at any time by either or both of the communicating parties, 
and are torn down when they are no longer required or if either connection end *dies". In 
essence setting up a connection involves establishing descriptors of various state and 
control variables at each end and bringing these into a synchronous state. A generic term 
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that covers both the communicating socket and the descriptor associated with it is 
connection end. 

Opening and Cloeing Connections; 

Connections are associations (between two sockets) that are set up and tom down. 
This can be done in many ways that are, strictly speaking, not a necessary part of the 
data stream protocol but more of a session layer issue (we discuss this at the end of this 
chapter). 

A connection end can be in one of two states: un^stablished and established. If both 
mds of a connection are established then the connection is said to established or open. 

Data ban flow on a connection only if it is established. 

We will place the restriction that there can be only one connection between a given pair 
of sockets. 

Connection IDs: 

It might appear from the foregoing that a connecti<xi could be idmitifled by the pair of 
socket addresses (e.g. node IDs and socket numbers of the connection mds). This wwks 
well as Img as we are dealing with a single network with no alternate routes and without 
intermediate store-and-forward processing. Otherwise, since connections might be set 
up and tom down between a given pair of sockets, packets from a previous invocation 
could show up in a later invocatim and possibly be accepted. This is not a c<Miimon 
situation but is not as rare as might seem at flrst glance. For this reason, each 
connecticm end when it is set up generates a connection ID. The two connection IDs taken 
together with the socket address pair uniquely identify the connectim. The size of a 
connection ID is a function of the rapidity with which connecticms are expected to be 
setup and broken down (ie how quickly will the ID wrap around) and the maximum packet 
lifetime. For our situation an 8-bit cmnection ID seems ample. 

Sequence Wumbcrs, Acknowledgement Numbers and Windows: 

All packets sent on the c(xmection carry a sequence number. This is used to ensure 
their in-sequence delivery, and duplicate packet filtering. Lost packets can be 
retransmitted using a timeout mechanism. Packets received correctly can be 
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acknowledged by sending back an MCknowledgem&it number, which is the sequence 
number of the next packet the end expects to receive over the connection. The size of 
these numbers is related to how rapidly packets will be sent out (again the issue of wrap 
around) and the expected maximum packet lifetime on the network. 

Flow control is done on the basis of credits or a reception window supplied by the 
receivinif end of a flow. This is a value that indicates how many packets beyond the one 
indicated by the acknowledgment number are welcome. This need not be equal to the 
number of available buffers, though that would be the simplest strategy. The 
acknowledgement number plus the reception window value (minus one) is the maximum 
sequence number authorized for use by the sending end. 

V7/.2 DSP interfece: 

The basic DSP calls are SEND-on-DSP, RECEIVE-from-DSP. [Connection opening and 
closing calls are discussed in section VI1.6]. It is assumed that when a connection is 
opened DSAP (part of the Oita Stream Access ProtoooX) returns to the connectiwi climit a 
Connection ReMum which. is used to identify it in the SEND and RECEIVE calls. Buffers 
for the connection are provided by the client when the connection is opened. 

(1) SEND-on-DSP : 

The caller provides the Connecticm RefNum, and DSP data length and pointer. A 
functim flag is provided to allow the caller to signal a logical «td at the mtd of that 
packet (thus the data stream can be interpreted by the receiver as having messages that 
end with these logical end marks) and for the purpose of sending connectiw interrupts to 
the other end. 

(2) RECEIVE-from-DSP : 

This is a means for polling the DSP module (or setting up a completion routine 
address) to see if any packets have been received on the connection. DSP returns the 
buffer address and DSP data length, as well as the logical end or cnmection interrupt 
indication. RECEiVE-from-DSP also serves the other important function of supplying 
additional receive buffers to DSP (or returning buffers in which received packets have 
been delivered to the climt by DSP). 
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VU.3 DSP P»cket Fornmt: 

Figure DSPl illustrates the DSP packet fwinat. The header cwisists of one byte 
source and destination connection IDs ("source* refers to the source of the packet), a 
one byte sequence number of the packet, a one byte acknowledge number, a four bit 
window field, and a four bit control field. The MS bit of the control field Is set to indicate 
a DSP control packet, ie one that does not carry any client data. The Request ACK bit can 
be set to force the destination to send a packet for the purpose of providing the latest 
values of its acknowledgement number and window value. 

A packet that has its DSP control bit set must not carry data and cannot have the 
logical or interrupt bits set. Such a packet does not consume the sequence number; the 
sending end sends the next packet with the same sequence number. 

If the DSP control bit is not set the packet contains client information, usually data in 
the DSP data part of the packet, though it could be just an interrupt or logical end 
indication. 

VII. 4 DSP Dialogue and Errw Recovery Mechanisms: 

The protocol dialogue in the normal situation is quite straightforward. Once a 
connection has been opened (see section VII.5), either end can send data packets to the 
other. Receiving ends of such packets can send out ACKs at any time though the sending 
end can force the return of ACKs by setting the Request ACK bit. Control packets can be 
sent at any time to elicit such information as well. 

The sequence number at the sending end is increased every time a non-Control 
packet is sent out for the first time (as opposed to retransmissions). From the window 
parameter sent by the other end, the sending end obtains a maximum permissible value of 
the sequence number (equal to the received acknowledge number plus the received 
window value minus one); client requests to send a packet when this value has been 
reached are rejected. 

Lost Packet and Out-of-Sequence Recovery; 

Each end has a RCV.NXT value which is the sequence number of the next packet it 
expects to receive from the other end. When a packet is received its sequence number if 
compared with this value. A mismatch causes the received packet to be discarded. A 
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packet received with the correct sequence number is accepted and if it is a non-Control 
packet then the RCV.NXT value' is incremented. Also, the receiving end maintains a value 
of its receive window RCV.WND. This grows and shrinks depending on the availability of 
receive buffers. 

Recovery from lost or out-of-sequence situations is resolved by using a retransmit 
timer at each end. Every time this timer expires, all packets sent by that end but not 
yet acknowledged are retransmitted. The reception of a packet with acknowledge number 
An causes all packets with sequence numbers through An - 1 to be taken off the send 
queue. 

la 

Half-Open Connections ; 

Another situation is that of one of the ends "dying* or becoming unreachable from the 
other. The connecticm is said to be half-open. In such a situation, the sending end would 
keep on retransmitting the packets in its send queue and would needlessly consume 
bandwidth. Even in the absence of traffic, resources are tied up at this end in the form of 
connectim descriptors, timers, etc. This situation is bandied by using a connection 
timer, started when the cwmection is opened. If the timer expires and no activity has 
been seen, then a probe (a control packet) is sent to the other «id. Failure to receive a 
respwise is taken to mean that the other end is "dead" or unreachable and the connection 
is tom down. 

V7/.5 Data Stream Access Protoaa: 

(to be described in a later version) 

VII. 6 Implementation Notes: 
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Control 



i Inttrrupt Bit 


Logical End Bit 

— Roduost ACK bit 
— OSP Control Met 




LAP Hauler 


OOP Header 


08P Header 


Figure DSPl. DSP Packet Format 
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Datagram 
Internets 
Named Entities 
Reliable Transport 


Gursharan Sidhu 
July 27, 1984 


• 19B4 §fpU CenpwtsT tne. 
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L Open System 

k. 

Ftt)tocols can be accessed and added at any level 

2. Versatility 

tiot designed for a specific purpose. Rather, 
rich enough to be essentially general p urpose 

3. Simplicity 

Protocols have been made as simple as possible to: 

• reduce code size and complexity 

• enhance performance 

4 Support Third Party Development 

Provide only the framework and basic 
building blocks and services 

i 

j 
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up to 254 different protocols can be located 
immediately above the LAP 







• Key Considerations/Goals 
and Overall Functions 


* LAP ^pe Field 



bitemets 


Named Entities 


■ Reliable T1»n^rt 
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Sockets are "owned” by socket clients 


Socket 

Client 


Stcket 


Socket 

Client 


Socket 

Client 


Stdtet 


Node 


a process (or "function" 
in a process) (software) 


Statically assigned : 

1-64. — reserved 

65. - 127. — experimental use 

Dynamically assigned : 128. - 254. 


• 104 40l* C« 9 utsr Ine. 






the protocol that implements the socket-to-socket 


delivery of packets (datagrams) 



• Simple, liest effort”, no retry mechanism 

for packet loss 


• 1M4 Cenputar Xne. 
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ABLAP 

Header 


DDP 

Header 




(single AppleBus) 
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* Key Gonsideratioxis/Goals 
and Overall Functions 



•LAP Type Field 

• Datagram Service 
•Internets 

• Named Entities 

• Reliable Transport 








ilC=jlr 


Backbone network 




[AppleButC [ 


AppleBui 0 


• Unique 16-blt network nnmbei 
for each network in the internet 

* Unique way of addressing 
a node on the internet 

Internet Node ID 
Network # : AppleBus Node ID 


(C) 19S« leeU Coepiitir Inc. 
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ABLAP 

Header 


DDP J 
Header^ 

(internet 

form) 


DDP Data 


Immediate Destination 
Node ID 


Immediate Source Node ID 


LAP Protocol Type — 2 


Hop Count 


Datagram Length (Itb) 





Destination Network 
Number 



DDP Protocol Type 


to 586 bytes 



2 bytes 


2 bytes 


— Source Network Number-| 2 bytes 


Destination Node ID 


Source Node ID 


Destination Socket Number 


Source Socket Number 


(c) 1964 »tpU CoMpwtat Inc. 


7/31/64 















Key Considerations/Goals 
and Overall Functions 



LAP Type FieU 
Datagram Service 
Internets 
Named Entities 


■ Reliable Transit 




1 

Addresses vs Names 

I 

k. 

Protocols use Addresses 
People prefer Names 

i 

I 


Addresses are Nwnl?ers 

are Character Strin gs 








“> Socket Qients 


ames of Network-Visible Entltt 


Entity Name 


< Object > : <Type> •<Zone > 


each part of the name is a 
string of up to 32 characters 


(«) MM Cwpwtw Inc. 
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Use this address to access the entity 
through its socket 















ND consists of the Names Table 
nodes of the internet 


in the 


contains 


< Entity Name, Socket Address > 


pairs for all named socket clients 



(e) 1M4 tipple Cenpwter Inc. 








2. This is received by all nodes that have 
implemented an NBP process 

3. Each of these NBP processes searches its Names 
Table; 

- if a match is not found it ignores the request 

- if a match Js found, it sends a datagram back 
to the lookup requester with the complete 
nameCs) and socket addressees) of the matching 

entityCies) 

4 The requester repeats this process several times 


(e) 1M4 CenpwtOT Inc. 
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Key Gonsiderations/Goals 
and Overall Functions 


LAP Type FieU 


Datagram 


Internets 


Reliable Transport 


• 1M4 %ple e«vi/tn Ins. 














Serv 


requester 


responder 


request, 


response 


Table 

of 

current 

requests 


response 


release^ 



2 ? 
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AppleBus 



WIRE CONNECTION TABLE 

OIN 
PIN # 

FUNCTION 

DIN 
PIN # 

1 

APPLEBUS -PLUS 

1 

2 

APPLEBUS-MINUS 

2 

3 

UNUSED 

3 

SHELL 

SHIELD 

SHELL 




AppkBus 




3-Pin Male 
Miniature Din 

Color: Apple Snow" Beige 


(c) 1M4 Itola Caapuur Xnc- 
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AppleBus 


Ap pleBus Cables 


2 Meters (6 Feet) 


6 Meters (20 Feet) 


15 Meters (50 Feet) 


Bulk Cables (PVC and Teflon) 



Connector 
Kits (6 units) 


500 Foot Cable Spool 


(c) ISM Oonptrttx Xne. 


34 


A ppleBus 



(e) 2M4 tppU CMputtT Zne 




(e) 1M4 H^U Coflpuur Zfte. 
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AppleBus Server Kit 



AppleBus Server Kit packaged with 
all Apple Server Products 


















AppleBus Components 



^nnection Module 








ptHin 4 TWT^ A 1_T\ ^ ^ 1 _ A 1 _ ^ _1 s-fe:*::?! 

km 1 







10 Meter PVC AppleBus Cable & Cable Extender! 
































AppleBus Starter Kit 






















AppleBus Assembly Kit 


























AppleBus Server Kit 



AppleBus Server Kit j>ackaged with 
all Apple Server Products 





















AppleBue Components 































AppleBus Starter Kit 





































AppleBus Assembly Kit 



600 Feet 
Teflon Cable 





Acfc^myklv P1ii<^« 
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AppleBus 



ABLAP 


Carrier Sense, Multiple Access 
w/ Collision Avoidance 




8-bit node addresses 
Unique only on single bus link 




FLAG framing, 

8-bit address, 
bit-stuffing, 

CRC-SDLC Frame Check Sequence 

(using CRC-CCITT polynomial - ♦ x** ♦ x* ♦ 

w/ initialization or I's) 


<e> 19M Ccnputar ine 





















AppleBus 


Problems to be solved: 

• station may not be listening 

• contention (collisions) 

• no true collision (carrier) sense 


Solution: 
3-way handshake 


Sender 


Ris- 

ers' 

DATA. 


Receiver 





DATA^ 

vvvvvvW 



time 




<e> i«M coi^ttf inc. 
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Performance Characteristics 

of . 

AppleBus 


as observed by the 

Ubung 

simulation system 


Mtf0rvl9M 


Apple Oamputer, tia 




Polling 

♦ guaranteed response time 
+ simple work for slave nodes 

- fix^ overhead 

- complex work for master 

Tokens 

+ guaranteed response time 
+ high channel efficiency 

- complex; difficult to implement 

Random access schemes 
+ easy to implement 

- inherently unstable % heavy load 


^qp/e ConpUer, Inc. 


Pure random access: 
ALOHA (c. 1970) 


Listen before transmitting: 
APPLEBUS (1984) 

Listen during transmissiort 
ETHERNETCc. 1976) 
APPLEfET (1980-198^ 


fipple ComfuAer, Inc. 


ALOHA 


Uhiversity of Hawaii packet radio 
network (9600 bps). 


^ VHF transceiver connects nodes to 
network (split charnel). 


^ Node sends at any time. Positive 
ACK required. Retransmit after 
random interval 


low capacity: ll2e = 1766 bps. 


slotted variant improves to He 


Apple Computer, Uk. 


Ethernet 

V CSM^CD: Carrier Sense, Mutliple 
Access with Collision D etection 

V Transmitting node monitors line and 
transmits when idle (1-persistent). 

J Transmission terminated when 
collision is detected. Retransmit 
after binary - exponential delay. 

V Inherently unstable. 

V Inefficient if propagation delay is 
large relative to packet tx time. 

Computer, Inc. 


AppleBus 



Data Rate: 230.4 kilobits/second 

Physical Data maximun 32 nodes 

maximum 1000 feet 

ElectricaL Balanced Signalling 

Standard RS-422 driver 
and Receiver ICs 

Transformer Isolation 
Passive Drops 

FMO modulation 

%plt Conpulti Irtc. 



AppleBus 


ABLAP 


Addressing 


8 bit Node IDs . 
Dynamically Assigned 
Broadcast packets allowed 


Framing 


SDLC (using bit stuffing) 


Access Control: CSMA/CA 


OATAPkt 


TlKe 


T random ( > 400 usee) 
t less than 200 usee 


4pplt Conputer Inc. 





Ubung Simulator 




Uk> to 32 nodes, Macs, Apple //e, 
Lisas: one master, 31 slaves. 

Operation 

Master controls testbed 

** configure nodes from config file 
" monitor performance and gather 
statistics. 


Statistics monitored 

" transmit queue delay 
" throu^iput 

” errors: CRC, fr a gnented 
packets, retries, etc. 


AppleBus 

Performance Analysis 


KBytes/sec 
35 
30 
25 
20 
15 
10 

5 

0 100 200 300 400 500 

Packet Size, bytes 

12 Nodes 



Afipie Carputar, Mic, 




AppleBus 

Performance Analysis 


KBytes/sec 
35 
30 
25 
20 
15 
10 

5 

0 100 200 300 400 500 



Size, bytes 

12 Nodes 


1 


^ppie amputee Ha 








EoUiog 

* guaranteed response time 

* simple work for slave nodes 

- fix^ overhead 

- complex work for master 

Tokens 

* guaranteed response time 

* high channel efficiency 

- complex; difficult to implement 

Random access schemes 
+ easy to implement 

- inherently unstable 9 heavy load 


^Dp/e Computer, Ihc. 




i 


AppleBus 

LAP delay distribution 
pipelay X packet times] 



Echo mode, 512 bytes packets, 14 nodes 

Apple OoTfMjter, Inn. 





AppleBus 

LAP delay distribution 
p[delay Xpacket times] 



10 * **100”° 


>1000 


Non-echo mode, 13 Nodes, 312 byte packets 


Apple Computer, Inc. 



Apple Computer, Inc. 



AppleBus 

Capture Effect 

MinMax Delta K vs Offered Load X 



Apple CompUla, tnc. 



Throughput K vs Offered Traffic X 
for selected access schemes 



Apple Computer, tia 






*»P^7f'cOf 







from Utxng 

✓ Strong 'capture’ effect biases 
service towards faster nodes. 

✓ Backoff algorithm breaks down 
when offered load is greater than 
- 0.80. 

✓ Very reliable when offered load 
is less than 80% channel capacity. 

^ Randomness of backoff algorithm 

• affecting performance? 

X Link-level NAK increases chamel 

• utilization with heavy loads? 


Computer, tne. 






from Ubung 


✓ Overruns reported on * 6-8% of I 
packets received (independent 

of load). 

✓ Underruns reported on * 2% of I 
packets transmitted, at offered 
load > 0.90. 

✓ packets (length < 8 bytes, I 
usually = 4 bytes) are received 
under heavy ( > 1.0) load, but 
infrequently. 

✓ Runt packets are received more I 
frequently (0.03%) with smaller 

(32 byte) packets. 

Runt formet; SrcAd(^, OstAdifr, STcAddr, $84 

Computer, Inc. 



AppleBus 


MacColleg e 

- Technical assistance to accelerate the 
completion of Macintosh programs 

- Restricted to experienced 
Macintosh developers 

- 3-day sessions beginning in 
Jlne. $500/session 


- Conducted in a dedicated facility 
complete with 13 Macintosh/Lisa 
development systems 


<e) itaa egyuttr Int. 
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AppleBus 



Prog ram 

Technical assistance for serious, 
commercial development of 

Macintosh and Lisa products 


Telephone 


- 24 hour turnaround goal 

- $500 for 6 month period 

- Enrollment limited to Apple 
Certified Developers 


CO IfM «pple CoHputer Inc. 



Workshops and Seminars 
Conferences 
Product Discoints 

Newsletter and Mailings 

Technical Information 


<e) i«M cottar inc. 




AfipleTalk Peak 

Version 2.0 

Richard F. Andrews and Gursharan S. Sidhu 
Network Systems Development 
e 1984, 1983 - Apple Computer Inc. 

The AppleTalk Peek program is a network tool used to monitor packet 
traffic on a single AppleTalk network. Peek runs on a Macintosh (with 
AppleTalk connected via the Printer port), and can record all packets 
seen on the bus. In addition, it can detect certain errors, measure packet 
arrival times, and display packet data in hexadecimal and ASCII format. 

Peek has enough queue space to hold a large number of packets. This 
queue is used in a circular fashion, so that Peek can continue to monitor 
packets even after the queue has been filled. Older packets are discarded 
to make room for newer ones. 


Tfie Window 

When Peek is started, the program's window is drawn. It contains the 
control buttons, menus, and information display areas described below. 


I START] 

I STOP ) 

Peek is always in one of two states: recording or displaying packets. 
When the program is first started, it is in the record state. The START and 
STOP buttons are used to initiate and terminate a recordina session. 
during which Peek listens on the bus and records traffic. 

When the START button is pressed, packet reocMrding is enabled. The 
button becomes gray to indicate that I^ek is recording (see Figure 1 ). 
Peek's internal buffers are cleared, and packets from a previous session 



are lost. The STOP button halts recording and causes packets to be 
displayed, if any were recorded during the session (see Figure 2). 


pPkts in Q-i 
0 


When the STOP button is pressed, the Pkts in Q box shows the number 
of packets in Peek’s queue. This box is not dynamically updated during a 
recording session, since queue wraparound makes this determination 
difficult. The word “Soap I i ng ” appears here while recording, as an 
indication that Peek is monitoring the bus. 

The size of the queue is determined by the amount of free memory, so 
that Peek running on a 5 12K. Macintosh will be able to record more 
packets than a 128IC Macintosh. Part of the queue memory is devoted to 
"bookkeeping” information. 


rPktS RCMd-i 
0 


The total number of packets seen by Peek since the start of the recording 
session appears in this box. This count is updated dynamically, and hence 
provides a rudimentary visual indication of bus traffic. Since Peek’s 
queue can wrap around and ’forget ” old packets, this count may be 
greater than the number of packets stt^red in the queue at that time. 

During a particularly long recording session, this count may itself wrap 
around (when it reaches 32,767} and become invalid. 


CRC errors; 

0 

Overruns : 

0 

Time Outs; 

0 


This box displays the tally of errors during a recording session. Peek can 
detect three types of errors: 

GtC errors are noted when the 16-bit Frame Check Sequence (FCS) at the 
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end of the ALAP frame does not match the calculated PCS. This indicates 
a possible error in transmission (due to noise on the bus, collisions, etc.). 

Overrun errors occur when the receiver reads bytes too slowly from the 
Macintosh s Serial Communications Controller (SCO, and this chip's 
three-byte FIFO buffer overflows. Note that if the node running Peek 
detects an overrun error, it does not necessarily mean that this will be 
the case for other nodes. This error is sometimes detected as a 
by-product of collisions on the bus. 

Timeout errors are flagged when a byte is ekpected on the bus (the end 
of the packet has not been seen, yet a byte does not appear on the bus 
within about 400 microseconds of the previous byte). Every byte 
received thus far will be stored and displayed as "the packet", even 
though the true packet end was not detected. This usually indicates a 
problem in the packet sender s hardware, but it may also be a by-product 
of collisions on the bus. 

The error fields are updated "on the fly " as packets are recorded, and are 
a measure of the total number of errors seen by Peek. Therefore, in a 
long recording session, it is possible, due to queue wraparound, for a 
packet to be received in error and not appear in the packet display, 
although the error is noted in the box. 

Go- Away box 

When you wish to terminate the Peek program, click in the small box in 
the upper left-hand OMrner of the window. 

Display box 

This box is used to view packets which were saved during the reccMrding 
session. Each packet is preceded by a banner line (see Figure 2) in 
boldface which includes, from left to right: 


• a set of square brackets which may contain blanks or one of the 
following characters: B if the packet was a broadcast, C, O, or T if 
a CRC, overrun, or timeout error, respectively, was detected for 
that packet; 

• the source S and destination D node IDs of the packet, in decimal 
format; 
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• the packet's arrival time T in milliseconds (measured relative to 
the first packet stored in the queue); 

• the time since the previous packet's arrival (delta time or AT); 

• the packet's sequence number in parentheses (in the order in 
which they were received, starting with zero for the oldest packet 
in the queue); 

• the calculated length L of the packet (number of bytes in decimal, 
not Including the FCS). 

Following this banner line are two displays of the packet's contents, in 
hexadecimal on the left and the corresponding ASCII (if printable) on the 
right. A period is substituted for any unprintable character. Note that 
the FCS is not shown. 

On the right side of the display box is a soroll bar which is enabled 
whenever there is more to be displayed than will fit in the box. The user 
can scroll through the display df packets by using the .scroll bar's np and 
down arrows, or by dragging the thumb. Qicking in the gray area above 
or below the thumb shifts the display backwards or forwards one 
complete packet at a time. This is useful for scrolling past large packets. 
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tlenus 


g'M Control Edit Search 

About the Peek Program... 


Scrapbook 
Alarm Clock 
Note Pod 
Calculator 
Key Caps 
Control Panel 
Puzzle 


The Apple menu, as usual, is used to invoice a variety of desk accessories. 
Choosing About the Peek Program will cause Peek to display some 
descriptive information, including the version number and the size of the 
queue in bytes. 



Gontrol 

Edit Search 


Short Format 

Receiue LAP Control Pkts 

Ulrite Packets to File 

Print Packets on imagelllriter 



The second menu is the Control menu, as seen above. When Short 
Format is selected, a check mark appears next to the menu item and 
packets are displayed in a more compact form. Only the banner line and 
the first line (up to the first 16 bytes) of each packet will be shown. The 
display can be scrolled as before. Choosing the menu item again will 
change the display back to long format. This item is inactivated during a 
recording session. 

When Receiue LAP Control Pkts is selected, all LAP control packets seen 
on the bus will be recorded. These are defined as any packets whose LAP 
type field is $80 through IFF hex (most significant bit set). Such packets 
will be recorded only when this option is selected. If their reception is 
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enabled in the middle of a recording session, any LAP control packets 
already seen on the bus will not have been saved. Qianging this option 
while viewing the display of a previous session will have no effect on the 
display, but will affect the neit recording session. 

Selecting Ulrite Packets to File will cause Peek to save away a copy of 
the display into a file on disk. If there are disks in the internal and 
external drives. Peek will attempt to write to whichever one has more 
free space. The name of the file will be “Peek Buffer 0", unless a file by 
that name already exists; in which case Peek will try 'Peek Buffer 1 " 
through "Peek Buffer 9". If those ten files already exist. Peek will give up 
and display an error message. 

If there is not enough room <m the disk to save all the packets. Peek will 
write as many as will fit, and notify the user that a "Write Error: -34" 
occurred. This means that the disk is full; you may wish to put an empty 
disk in the drive and try again. The file containing saved packets will be 
of type "TEXT" and creator "EDIT". 

As an alternative, you may choose Print Pockets on Imogeivriter. 
Connect an Imagewriter to the modem port (nst the printer port) before 
selecting this item, and Peek will print the entire display on the printer. 
(This could be a time-consuming process if there are many packets to 
print). Note that the Short Format option (described below) has no effect 
on packets written to a file or to the printer - long format is always used. 


tl Control 

Edit 

Search 


Cut m 

Copy 3§C 
Paste 98U 



The Edit menu is used only in conjunction with the Find Pattern feature, 
described below. It allows you to use the standard text edit commands to 
create a string for which to search. 
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# Control Edit 




Find Pattern S€F 

Find Same §^S 


Find Ouerrun 
Find CRC Error 
Find Timeout 

Search is Not Case Sensitiue 


The Search menu is used to look for a particular hexadecimal or ASCII 
string within the recorded packets. Selecting Find Pattern (or the 
equivalent command key-F combination) will cause the Find window to 
appear, as in Figure 3. Select Henadecimal or Rscii, and type in the 
string for which to search. The standard text editing features available in 
the Edit menu may be used. Hex strings must be a sequence of bytes, 
each specified as a dollar sign ($) followed by a two-digit hex number. In 
either format, a wild-card may be specified by the command key-equals 
sign combination. This will appear in the Find window as and will 
match one or more characters of any value. 

When the string has been entered, hit Return or the Find Nent button. 
Peek will begin searching from the first packet appearing in the display 
box. The display will be scrolled down to the packet containing the 
string, if found, and the string will be highlighted. Otherwise, Peek will 
inform you that the string was not found. Selecting Find Same (or the 
equivalent command key-S combination) will cause Peek to look for the 
next occurrence of the same string, starting from the current packet. 

Find Ouemin, Find CRC Error, and Find Timeout work in a similar 
fashion. Selecting one causes Peek to search, starting from the first 
packet in the display box, for a packet exhibiting the particular error. If 
found, the display is scrolled to bring that packet to the top of the box 
(unless it is too close to the last packet to scroll up to the top). Since the 
error counts are cumulative from the time the STRUT button was pressed, 
packets with errors may not always appear in the queue (if they were 
discarded to make room for newer packets). 

The search can be made case-sensitive or not case-sensitive by selecting 
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the item Search is Not Case Sensitiue. The menu item will display the 
current state of this option. 


Notes 

1. The newer versions of Macsbug (1/1/85 or later, with symbols) tend 
to slow Peek enough that it will frequently overrun. Use older 
debuggers on your Peek disk ot none at stM- 

2. A node running Peek is in listen-only mode on an AppleTalk network. 
Such a node does not participate in the ALAP protocol and does not 
even consume a node ID. In fact, it is ‘'invisible ' to other nodes. 

3. Peek does not use any of the standard AppleTalk drivers (e.g. the 
Macintosh Protocol Package), but assumes direct control the 
Macintosh's AppleTalk port. However, the port is reset when Peek 
terminates, so it is possible to then run other AppleTalk software 
without powering down the Macintosh and powering it up again. 

(Note that this is not true for versions of Peek older than V2.0). 

4. Peek will not run on a Macintosh XL under MacWcurks. 

5. If a packet that is longer than <4095 bytes is received by Peek, its 
subsequent behavior becomes unpredictable. If Peek terminates 
abnormally during a recording session, there is a strong probability 
that a node on the network has sent a packet of illegal size (e.g. a node 
is stuck in its transmit loop). 


a^duiotiMfed ^ ctn c t i ts 


This program borrows ideas from a former Lisa Workshop application 
developed by Jim Nichols and Steve Butterfield; in particular, the circular 
use of a buffer. AppleTalk Peek is a completely new program designed to 
exploit the Macintosh user interface. Thanks to Mark Neubieser and Paul 
Williams for implementing new features. 
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Figure J: Peek Window (Recording State) 








ll Control Edit Search 



AppleTalk Traffic Peek 


CRC errors; 
Overruns : 
Time Outs: 



20 61 FF 73 64 66 6fl 39 38 20 61 39 64 20 20 61 
73 70 99 30 61 30 66 20 30 38 6C 61 73 64 20 61 
73 27 14 66 38 6F 61 64 70 72 30 33 33 6C 34 2C 
20 20 27 61 73 66 70 OF 6F 61 58 20 6F 61 30 64 


■1^ 


20 73 

IB I S: 10 
FF OR 84 
IB ] S: 10 

FF OR 01 


O: 255 T: 25885 


0: 255 T: 

00 7F 00 00 


25885 

03 38 


6C 64 


AT: 32 

AT : O 

73 66 6E 


65 68 
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B^leTalk Poke 

Version 3-1 


GeneTyacke 

Network Systems Development 
• 1964,1963 - Apple Computer Inc. 


AppleTalk Poke is a Macintosh application designed for use by 
AppleTalk developers. It allows the user to edit/create packets and to 
send them out on AppleTalk. Developers are espected to use Poke to test 
their protocol software/hardware implementations lor AppleTalk 
products. Poke uses the Macintosh Protocol Package CMPP) for AppleTalk 
access. (Det^ of MPP are discussed elsewhere) 

This document describes the features and use of Poke. It is not intended 
to instruct the user on the capabilities, features, or specifications of MPP 
or of the various AppleTalk protocols, nor does it discuss the normal use 
of the Macintosh's standard editing abilities. (For information on 
AppleTalk protocols, see the corresponding spedfication/description 
document) 


Startup 


After starting Poke, the MPP driver is loaded in (if it isnt currently in 
memory) and the main window is brought up (figure 1). This window 
displays the Poke station's AppleTalk node ID and packet information. At 
this s^e, the packet information indicates that no packets have been 
loaded into Poke (packet names are all set to empty). Next to each packet 
name, there is a pair of buttons labeled EDIT and SEND. Initially, all SEND 
buttons are dimmed (inactive) because no packets have been loaded. The 
main window includes an area for displayii^ any appropriate error or 
status messages. 

The program operates in two different states. When started up, it is in 
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the send state with the main window displayed. When any EDIT button is 
pressed, it goes into an edit state and the packet editing window is 
displayed (figure 2). In this state, the selected packet can be edited. 
Clicking the edit window’s OK button will return you back to the main 
window and the send state. 


tlemis oiui CDtimuitufe: 


Poke’s menu bar contains four menus. These are: 


i # File Edit Tools 


Each menu and its associated commands is displayed and described 
below: 

Menu: 



File Edit Tools 


All About Poke... 


Scrapbook 
Alarm Clock 
Note Pad 
Calculator 
Key Caps 
Control Panel 
Puzzle 


The "Apple" menu allows you to run an available desk accessory or to 
examine Poke’s version information ("Dll Hbout Poke..."). Selecting the 
"All About Poke..." command brings up an information window. Clicking 
the mouse or pressing a key causes this window to disappear and Poke 
returns to its original state. 
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File 

Menu: 



Edit 


Load 

Saue 


Quit m 


Tools 


The File menu allows the user to load from (or save to) a file of 10 
prepared or canned packets. The Load and Saue operations follow the 
standard conventions for file loading and saving. Note: Older versions of 
Poke utilize a different file format You cannot load in packets created by 
those versions. 


Edit 

Menu: 


d File 


Tools 


Cut m 

Copy dgc 
Paste 3§U 



The Edit menu is used only while editing a packet Please note the 
keyboard's optional command keys that can be used to invoke this 
menu's commands. 
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Tools 

Msntt: 


t File Edit 


Tools 


Clone Packet 

Shoui Packet Length 9§L 

Helpful Hints m 

Set Repeat Factor 
Rbort Send If Error Occurs 


Calculate Checksum 


"Clone Pocket* can only t>e selected from the main window. When 
selected, a dialog boz appears which asks you for the name of the packet 
you wish to copy (the source). It also asks for the name of the packet 
which it is to he copied to (the destination). The names are searched in a 
top to bottom fashion starting at the top left comer of the main wmdow 
(figure 1). The first packet whose name matches the one you entered will 
be chosen. If both source and destination names are found, then the 
source packet will be copied verbatim to the destination. Otherwise, an 
error message is displayed. 

The "Shoui Packet Length" command can only be used while editing a 
packet It returns the number of bytes in the packets data field. This 
count does not include the packets header, so the actual packet size will 
be larger. (See the AppleTalk protocol documentation for information on 
the size of the different headers.) If an error is detected while computing 
the length, an alert boz will be displayed indicating the ezact location of 
the error. Note: If you have entered more data into a packet than is 
allowed by the corresponding protocol (LAPJ)DP,ATP) then Poke will 
truncate the data (at the end) to the mazimum allowed value. 

The "Helpful Hints" command allows you to obtain a quick summary of 
editing instructions. Clicking the mouse or pressing any key will return 
you to the currently active Poke window. 

Packets can be transmitted repeatedly at user specified intervals. The 
number of times a packet is transmitted and the time interval between 
transmissions are set by the user by selecting the "Set Repeat Factor 
command. This command will allow you to change transmission 
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information used by the SEND command (discussed later). 

The delay time interval between transmissions is given in ticks ( 1 tick » 
1/60 of a second). If you enter a number of transmissions value equal to 
zero, then Poke will keep sending packets out in a closed loop (i.e, 
indefinitely). When Poke is in such a loop, you can stop the SEND 
operation by either clicking the mouse button or by pressing a key. If 
you wish to send packets out at the fastest rate possible, enter a zero for 
the time interval. If this is done, packet statistics will not be displayed in 
the messages box. 

Note : The user specified time interval is achieved only approximately. 
Network loading and ALAP overhead plus packet transmit time add to 
this interval. 

The "Rbort Send If Error Occurs" command is used in conjunction with 
the SEND operation. If selected, a checkmark will appear on the left side 
of the command informing the user that this feature is active. Now, if an 
error occurs while sending a packet, the SEND operation will abort To . 
deactivate this feature, select the command again and the checkmark will 
be removed. This command is especially useful when large numbers of 
packets are being sent out 

The last command, "Calculate Checksum", may be used in the edit 
window to replace the existing DDP checksum field with an updated 
checksum. This command is only valid with packets utilizing the DDP 
long format (LAP Type field X2). 
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Preparing a Packet 


¥rh«n you pross tho odit button for a particular packet in the main 
window, tho edit window of figure 2 will appear and you will be shown 
the information of that packet This window is divided into two main 
sections: the header and the data, with Id editing fields. Only one editing 
field is active at a time. This is indicated by highlighting that field’s 
rectangular box. There are several circular buttons, check boxes and 
command buttons (OK, CANCEL and CLEAR) used in preparing the packet 
The standard Macintosh editing features apply to most of these controls. 
Some, however, need further clarification. These are: 

o Pressii^ the TAB key causes Poke to verify the information in 
the current field before activating the next field. The same is 
true if you press the lETUAH key (except within the packet's 
data field). If an error is detected while verifying a field, a 
beep will sound and Poke will return you back to the error's 
location. (Possible errors are described at the end of this 
section.) 

0 Clicking the mouse on a different editing field will verify the 
information in the currently active field. If there are no 
errors. Poke moves to the field clicked on. 

0 You may type data beyond that visible in the field. Leading 
blanks are automatically removed in the packet header fields. 


Entering the Packet's Name 

The packet's name is used only to visually distinguish the various packets 
from others in the main window. It may contain any sequence of 
printable characters, but it is suggested that you limit the number of 
characters to 16. 
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Entering Information in ttie Header Fields 

Information in ttie packet header fields can be entered in any one of 
three ways: 

Ttedmai : Type in the digits (eg. 12d). This is the default 

entry type. 

Headedmal : All hexadecimal (hex) numbers are preceeded by a 
dollar sign (eg., $d0 - 12d). 

Binanr Binary numbers are preceeded by a percent sign 
(eg.,*llll-$0F. 15). 

¥ 

Leading zeros are ignored. When a field has been verified, the number 
entered is automatically converted to hex format 


Possible Error Conditions: 

0 Value in field is out of range, (see AppleTalk ihrotocol 
documents for the permissible ranges of the various fields) 

0 Unknown character in field. Valid digits for decimal format 
are [0..91 (where this represents a range from zero to nine); 
valid digits for hex format is [0..9, a.i, A.Fi and valid digits 
for binary numbers are (0, 1]. 


Entering Packet Data Informatien 

The following format must be followed when entering information into 
the packet data: 

Data bytes can be entered into the packet in two ways: by typing in the 
ASCII character corresponding to the byte’s value or by entering the 
byte's value in its hex form. 

To enter the hex form, type a T followed by the two digit hex number 
(eg. $d4,$01). Note that ‘Ir is invalid, you must enter ”$01". Byte’s 
whose value corresponds in the ASCII code to a graphic character can be 
entered by just typing in that character. Example- to enter a byte with 
the value ’$62", type "b"; for "$42" type "B"; for ’$31“ type "1". Other 
examples can be found in figures 2 and 3. Note: Since the dollar ^ ($) 
is a special character, you can only enter it in its hex form ”$24". 
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Poke will detect errors from the end of the data back to its beginning. 

Idittag Buttons 

Various buttons in the edit \^dow control the information that 
constitutes the packet Each set of buttons is described below: 


Packet Type: QLBP ODDP ®BTP 

The Packet Type buttons are used to choose the header type as described 
in the protocols document After clicking on a button, only the fields 
appropriate for that protocol type will be shown. The default is RTP. 

Only one button may be selected at a time. 


O Beq (§) Rsp O Bel 

These three buttons are only used for an ATP packet They are used to 
format an ATP request^ response or release packet The default is Req. 
As above, only one button may be chosen at a time. 


□ HO GEOM GSTS 

Each of these check boxes represents the corresponding bit in the ATP 
control field. If checked, the corresponding ATP control field bit will be 
set otherwise the bit is cleared. 


r Packet Data Display - 

OHeK ^ ASCII 


The Packet Data Display buttons allow the user to select the type of 
display for the packet's data: hex strings or mixed ASCII and hex. INote: 
This operation may take up to 10 seconds for large packets.] If an error 
occurs during the format conversion, an error message is displayed and 
the conversion will abort You may enter data in either format at any 
time. The above buttons are used only when the display is updated or 
when you wish to convert data to the format immediately. 
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f CANCEL 1 


f CLEAR 1 


The OK button should he pressed when you are through editing the 
packet All fields are verified for correctness and the packet length is 
displayed before returning to the main window. Tou will also have the 
option, at this time, to calculate a checksum for the packet If any errors 
are detected, you will be returned to the edit window. 

The CANCEL button terminates the editing session without saving any 
changes to the packet The packet is returned to the original form that it 
had prior to this editing attempt Poke returns you to the send window. 

The CLEAR button clears all editing fields and inserts the default 
information into them. 


Sending fHicfects 


To send packets. Poke must be in the send state (i.e., displaying the main 
window). Any one of the ten packets may be sent by dick^ on its 
active SEND button. The number of times the packet will be sent and the 
delay between each of these transmissions is shown at the top right 
comer of the main window in the short form: 

Rpt Factor -nxid ticks 

where: n > number of transmissions 

d > time interval between transmissions (in ticks) 

If a SEND button is inactive, you must first edit the packet The result of 
the SEND operation is displayed in the message area at the bottom of the 
main window. 


able Error Conditions: 


0 No error; packet was sent to destination node (or broadcast) 
0 -93; Packet was unable to be sent because either the 
destination node did not respond or the line was sensed ‘in 
use" 32 times. 
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startup Notes: 


Wben Poke starts up, ttie MPP driver is opened and initialized. If the 
open call fails and you are returned a -33 error, you will be forced to 
exit the program. Most likely the cause of this error will be that the MPP 
driver is not installed in the System resource file. In addition, if the 
system heap is fragmented such that the MPP driver cannot get enough 
memory to load, the same error will be returned. 

If the serial port configuration byte (SPConfig) is not set correctly, you 
will get a -96 error when Poke starts. See the AppleTalk Manager 
manual for additional information on location and contents of this byte. 


Caveats: 

o Editing of the pocket’s data field will slow down appreciably 
as its size increases. Whenever possible, display it under the 
ASCII mode to minimize the number of screen characters. 

o While in the ASCII di^lay, all characters in the printable 
ASCII range (S20-S7E) and RETUIM ($0D) wiU be displayed 
in their ASCII form, even if they were entered as hex 
strings. 

0 The packet data field is limited to 33 Even short 

packets (e.g., entering more than 33 carriage returns in the 
packet’s data field in ASCII mode) can go out of the scrolling 
range. 

0 Numbers cannot be entered into the packet’s data field in 
decimal or binary format 

0 In no case can the size of the packet be greater than 603 
bytes, including ALAP header. 

0 If an error occurs while verifying or converting the packet’s 
data field, the information at the error location may change, 
as Poke tries to back out of the error gracefully. 

0 If you have chosen DDP or ATP packet types from the edit 
window, DDP long format will always be displayed, even if 
the ALAP type of $0 1 (short format) was entered. 

0 If you enter more than 600 bytes of packet data, the 
checksum calculation may not work correctly until you have 
exited and reentered the editing window. (This will truncate 
off all excess data from the end of the packet). 
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Fi gure 1. Main Window 
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■ Packet Data 

This is ASCII data. If I wish to enter unprintable characters, I enter T 
characters like: $00, $01, $2^ (dollar signl. 
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Fi gure 2. ASCII Displa y 















^ ^ File Edit Tools 


Packet Name; |DDP long header | Packet Type; OEAP (§)DDP O BTP 

Heoder Data 


""""Hi 

V 



- Packet Data = 

$54$68$69$73$20$69$73$20$4 t$53$43$49$49$20$64$6 1$74$a 1$0D$00$0D$0D$0D$0D$54$ 
ae$69$73$20$69$73$20$a8$65$78$2D$64$6l$74$61$20$69$6E$20$74$68$65$20$77$59$a 
E$64$6F$77 


-Packet Data Display - 

(g)HeH ORSCII 


I 




Fi gure 3. Hex Data Displa u 













